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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
