On 2019-05-30 20:27, Thiago Macieira wrote:
On Wednesday, 29 May 2019 08:17:15 PDT Mutz, Marc via Development
wrote:
But of course, that's a fallacy, because as soon as Qt internally uses
said inline functions, every use of them by the user with a different
STL is an ODR violation and therefore UB. So, again AFAICT, the
decision
was that we can use std types in the API now, even when not inline.
That's not correct. Keeping from the ODR violation is exactly why
libc++ uses
std::__1 namespace for its types. This allows for perfectly and
strictly
correct separation between a Qt internal use of std::vector and the
user's use
of std::__1::vector.
*Some* symbols aren't namespaced, like std::exception and
std::type_info. But
that's still not an ODR violation because the two implementations are
strictly
compatible: the layout is the same. That's true too for the the classes
in the
abi namespace, like abi::__si_class_type_info. There's a requirement on
how
the two libraries are built, but if it's wrong, it's just a
distribution
issue.
You talk about a particular incarnation of stdlibs, I was talking about
the general case. Yes, in the case you describe, and _if_ libc++ is
configured to be compatible (which in the past you have complained is
not done correctly), then it may work. But take STLport vs. Rougewave on
older SunCC. Or Dinkumware vs. GCC on QNX.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
