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

Robin Burchell robin+qt at viroteck.net
Mon Jan 30 14:36:32 CET 2012


Hi,

2012/1/30 João Abecasis <joao.abecasis at nokia.com>:
>> After thinking some more about this, my current thinking is:
>>
>>     drop the -no-stl support
>
> For the record, I'm all for this

Me three.

> Some points for further consideration:
>
> * Does that include everything in the standard library, or only the
> inline template stuff?

I'd take it on a case-by-case basis. Let's start with algorithms, and
see what else we can find useful. Ultimately, the less code we have to
maintain the better, but we should make sure that there are no obvious
downsides to such an exercise too.

> Some things, like <iostream> (<locale>?) don't make a lot of sense for
> us to use. Others like <thread> and <atomic> are interesting to at
> least consider in the context of C++11. (<regex>?)

Yeah. I don't consider those too useful. <thread>/<atomic> might be
useful in some years once compiler support has matured a bit, but I
don't see it being too mainstream yet. <regex> I don't see as being
useful because different regex have subtly different behaviour - so it
isn't like we can just yank PCRE out of QRegularExpression and have
everything just continue working, for instance. Same note about
compiler support applies here of course.

> Do we need an explicit policy or is common sense sufficient?

I'd say it's mostly a matter of common sense. Let's introduce changes,
have the appropriate people review those changes, and reject them if
they don't make sense.

> * Do we allow standard library types in our interfaces/ABI?

"it depends". I'd be wary about that. We do have guarantees to provide
after all, and we can't provide them when we're exposing code that
isn't ours.

BR,

Robin



More information about the Development mailing list