On Friday, 4 April 2025 08:07:27 Pacific Daylight Time Milian Wolff wrote: > Because if you do so, and the type is public (i.e. all-inline), then you > would not be able to safely put that into a `std::any` in one DSO and > extract it in another DSO. The worst thing is that this is only detectable > at runtime. In the context of Qt, maybe not a lot of people use std::any > (yet?), but being compatible with std types should be paramount I hope you > all agree.
This is not news. It's the same old dynamic_cast<> and typeid() and exception- throwing failure that we've known for over 20 years. If the class in question is not exported — and most simple, non-polymorphic classes will not be! — and you compile with -fvisibility=hidden, then the typeid will be emitted per shared library / DLL and will be hidden too. This implies the pointers to the same std::type_info obtained in two different DLLs will be different. See: https://gcc.godbolt.org/z/es97foYa4. Note how the typeinfo object is marked .hidden. We have the same problem with QMetaType: https://qt.godbolt.org/z/YaKzEMcoT. Note here how the QMetaTypeInterface object is also marked .hidden. The conclusion from this is that, from the point of view of the C++ language, they *are* different types, even if they have the same mangling and can (and are) passed across library boundaries in by value, by pointer, in containers, etc. The big problem here is that the C++ standard does not recognise shared libraries & DLLs exist, so this is an area that is underdeveloped. Despite being the mainstream. IMNSHO, this needs to be addressed in the Standard, ahead of modules even. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
