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

[Thiago Macieira]

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>
	not necessary: c-stuff (cstddef, cfloat, cstdint, etc.)
 - parts of the general utilities library (chapter 20)
	<utility>: std::move, std::forward, std::remove_reference, std::swap
	<type_traits> (C++11)
 - 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

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)
 - the localisation library (chapter 22)
 - the containers themselves (chapter 23)
 - 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.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120130/635fe7d6/attachment.sig>