[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