[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Mutz, Marc]

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