[Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)

[BRM]

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
<snip>
>> >  - 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 
>operator new).
>
>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.)


$0.02


Ben