[Development] Deprecation/removal model going into Qt 6

Thiago Macieira thiago.macieira at intel.com
Wed Jun 5 17:17:18 CEST 2019


On Wednesday, 5 June 2019 06:31:25 PDT Olivier Goffart wrote:
> That's where inline namespaces could help. (You'd change the name of the
> inline namespace as well so you could link to two libraries that use
> different version of Qt, and it would work. (as long as each of these
> library don't expose Qt in their interface))

Yes and no. Yes, you could use inline namespaces to allow both libraries to be 
loaded into memory at the same time. 

But this is of limited usefulness if the entire library is namespaced, since 
you can't exchange data from one to the other, except using non-Qt data 
structures. If you accidentally loaded a plugin linking to the wrong version, 
the act of loading wouldn't cause a crash. But you may well do so because 
plugins usually have a C interface to provide an access point, which will 
cause a loss of the actual type information.

For example, if the plugin has
    extern "C" QObject *interface();
and QObject is inline-namespaced into v1 and v2, then if he caller does:

    using Fptr = QObject *(*)();
    auto init = reinterpret_cast<Fptr>(library.symbol("interface"));

That reinterpret-cast is causing a problem and could cause a crash.

Instead, the entry point needs to carry no C++ symbol, such as:
    extern "C" void initPlugin();

And with that, the proper symbols are found by the correct namespaces.

And still cause problems. Imagine one of them needs qApp, but since it's the 
wrong version, qApp == nullptr.

Conclusion: you can prevent immediate crash in the case of accidental loading 
of the wrong version, but it's still such a horribly bad idea to make that 
load, to the point that it's not worth our time.

> Having inline namespace could also in theory then allow to link both with
> Qt5 and Qt6 in the same process.

The ELF symbol versioning can already do that.

> But a namespace has the other inconvenient to break every forward
> declaration.

And that.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products






More information about the Development mailing list