[Development] Use of std::function in Qt API

[Simon Hausmann]

I feel the same: Let's limit our binary compatibility promise to the part that we can control. That would be Qt itself.

Anyone attempting to build a system with a wider scope of binary compatibility promises needs to also control the shipment of other components, such as libstdc++/libc++, libgcc and others.


Simon

> On 14 Mar 2017, at 17:20, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
>> On terça-feira, 14 de março de 2017 09:01:25 PDT Ville Voutilainen wrote:
>> Ahem, it's not like there weren't qualms about it, but doing it for
>> std::string and std::list
>> was eventually necessary. The libstdc++ developers (including myself)
>> spend fair amounts
>> of time and energy trying to avoid abi breakage, including abi
>> breakage in downstream libraries.
> 
> I know, and we're grateful for 7 years of no breakage. It was good while it 
> lasted.
> 
> But then it happened, as we all knew it would. And then it happened again, in 
> a separate release, instead of everything in one release.
> 
> The cxxabi people also keep a document about a v2 of the ABI itself, so that 
> will happen some day.
> 
>>> What we have to ask ourselves is whether we want to say that is not our
>>> problem. For example, the std::string breakage caused any application or
>>> library that used it in its API to need to be recompiled. Besides Qt,
>>> there
>>> aren't many libraries that avoid it. So if the underlying C++ Standard
>>> Library breaks ABI, should we try to work around it? Or should we punt
>>> the problem to the user?
>> 
>> I don't know. What do our users want? How big a problem would it be for
>> them?
> 
> Right. See also the libc++/libstdc++ mix, which Linux distributions have not, 
> after years of shipping libc++, done properly. So it seems like mixnig is not 
> a desired use-case.
> 
> Given that, I'm beginning to think that we should change our policy.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development