Sorry, I'm a little late to the conversation - got behind a bit... > From: Thiago Macieira <[email protected]>
>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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
