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

André Pönitz apoenitz at t-online.de
Tue Mar 14 18:33:15 CET 2017


On Tue, Mar 14, 2017 at 08:54:06AM -0700, Thiago Macieira wrote:
> On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote:
> > Hi,
> > 
> > 
> > I understand that there are limitations (to put it mildly) regarding the use
> > of API from the C++ standard library in Qt API itself due to the inability
> > to extend our binary compatibility promise. I'm curious though whether
> > std::function falls under the same umbrella?
> 
> It does. libstdc++ has shown they have no qualms about breaking binary 
> compatibility in downstream libraries, as they've done it twice in the past 
> three releases (the most notable case was std::string).
> 
> 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?

The main point here is "besides Qt, there aren't many libraries that avoid it",
and that's, fortunately or not, very true. In practice people do typically not
expect a C++ application surviving Standard Library ABI breakages without
recompilation.

In general, I am not overly sold on ABI compatibility promises. I personally
could live without and find SC of more practical value. The most important
"feature" of ABI compatibility guarantee for me is that it limits people from
doing overly excessive source-incompatible changes.

I wouldn't go all-in at once, but by now the advantages of allowing
std::function in the Qt API outweigh any potential gains of not using it by far,
so "punt the problem to the user" sound just fine to me, also when wearing a
user's hat.

Andre'



More information about the Development mailing list