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

[Olivier Goffart]

On Monday 30 January 2012 16:13:48 Thiago Macieira wrote:
> On Monday, 30 de January de 2012 13.41.10, João Abecasis wrote:
> > * Does that include everything in the standard library, or only the
> > inline template stuff?
> 
> The STL is big and you're right, there are some things we don't really need
> or want to use.
> 
> > 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>?)
> 
> My suggestions. (chapter numbers are the same in both standards)
> 
> 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

> 	not necessary: c-stuff (cstddef, cfloat, cstdint, etc.)

I'd like to.  Why would we need to reinvent the wheel for those.
For example, I would also use <cmath>  
(becuase stuffs like the builtin std::abs are much better than our NIH qAbs 
does conditional jump)

>  - parts of the general utilities library (chapter 20)
> 	<utility>: std::move, std::forward, std::remove_reference, std::swap

> 	<type_traits> (C++11)

but, <type_traits> is not supported everywhere, so we always need a fallback, 
so that's boring.

>  - interoperate with the strings library (chapter 21)
>  - interoperate with the containers library (chapter 23)
>  - parts of the iterators library (chapter 24): traits and tags
>  - the algorithms library (chapter 25): <algorithm>
>  - the C++11 atomic operations library (chapter 29)
> 	implementation hidden in qatomic_cxx11.h
> 
> We possibly want:
> 
>  - pairs and C++11 tuples (chapter 20): <utility> and <tuple>
>  - C++11 memory (chapter 20): declare_reachable et al, addressof, pointer
>    traits
>  - functional (chapter 20): std::unary_function, std::binary_function, C++11
> function binding
>  - the C++11 thread support library (chapter 30), with hidden implementation
> and if they meet our needs

Again, using C++11 standard library must be limited to ours headers, with 
Q_COMPILER_XXX

> We don't want or need:
> 
>  - the diagnostics library (chapter 19)
> 	<stdexcept>, <system_error>, <cassert>, <cerrno>
> 	(we don't use the C or C++ errors, we go straight to POSIX or Win32
> 	 errors, which means errno.h in POSIX systems, not cerrno)
>  - the strings themselves (chapter 21)

If we do the interpolability we have to use them.

>  - the localisation library (chapter 22)
>  - the containers themselves (chapter 23)

Why not?

>  - the iterators themselves (chapter 24)
>  - the numerics library (chapter 25): complex, valarray, numeric
>  - the input/output library (chapter 26)
>  - the C++11 regular expression library (chapter 28), we've settled on PCRE
> 
> > Do we need an explicit policy or is common sense sufficient?
> 
> Like the above?
> 
> > * Do we allow standard library types in our interfaces/ABI?
> 
> If they match the list above, I think so. That would mean we accept types
> like std::forward_iterator_tag, std::unary_function, but not std::list.
> Those would mostly appear in template types and they would mostly be
> invisible to the user.
> 
> The only type I'm thinking we should really dump and use STL's is
> QPair/std::pair. What do you think? It's not like QPair is
> reference-counted.

> > 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.