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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
