[Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)
bm_witness at yahoo.com
Wed Feb 1 18:15:19 CET 2012
Sorry, I'm a little late to the conversation - got behind a bit...
> From: Thiago Macieira <thiago.macieira at intel.com>
>On Monday, 30 de January de 2012 16.32.38, Olivier Goffart wrote:
>> On Monday 30 January 2012 16:13:48 Thiago Macieira wrote:
>> > We definitely want:
>> > - the language support library (chapter 18)
>> > <limits>, <new>, <typeinfo>, <initializer_list> (C++11), <exception>
>> <typeinfo> and <exception> only in QT_NO_EXCEPTIONS and QT_NO_RTTI blocks
>> > - the strings themselves (chapter 21)
>> If we do the interpolability we have to use them.
>DId you mean interoperability? Because I really do not understand why you'd
>want to interpolate strings...
>My point here and below with "the containers themselves" is that we don't want
>to use those containers in our code nor in our API.
Having read the thread, I agree that it probably needs to be on a case-by-case basis, and I see where Thiago is going.
However, I think things like QString's interface to std::string (QString::toStdString()) are very useful; the interoperability in that respect.
I do agree that the Qt API should not make references to the STL or other APIs outside of these conversion interfaces - that just doesn't make sense.
The conversion interfaces however can be invaluable when interfacing with non-Qt code. I hope this is what you mean by that last line.
My own library projects tend to consist of two groups of code: (i) Qt-based code, and (ii) Standard C/C++ and STL code.
It is very useful to be able to have some of those conversions - like QString::toStdString() - built into Qt to help with making the two inter-operate.
It is also something that really helps make Qt stand out and enables projects to move towards using Qt.
>> > - the localisation library (chapter 22)
>> > - the containers themselves (chapter 23)
>> Why not?
>> > > In general, I would think not. Still most standard libraries keep their
>> > > ABIs stable for long periods of time such that it might not be a big
>> > > issue to allow *some* types to go in our ABI.
>> If a compiler breaks its ABI, everything needs a rebuild anyway, including
>> Qt that use those stl implementation anyway.
>> So that argument is moot I think.
>A compiler could break the standard library without breaking the ABI and Qt
>could survive such a change unchanged and not rebuild. This is more true of
>the more complex, non-inline classes than the basic language support (like
>In practice, it's not likely to happen and, even if it does, chances are you
>need to recompile anyway just because of the library dependency.
I understand this point; but still find the above to be an extremely useful feature of Qt.
I also do not really see much of the need for having the "no stl" option except in some really rare embedded cases; having those conversions, IMHO, should be a standard part of Qt for the reasons above.
Now whether or not STL is utilized internally for certain things, like Thiago mentioned for std::atomicbeing used behind the scenes, is a slightly different issue than I am trying to address; but if its useful and stable enough then I don't see why not. (But that's as far as I'll go there right now.)
More information about the Development