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

[Thiago Macieira]

On Monday, 30 de January de 2012 16.32.38, Olivier Goffart wrote:
> On Monday 30 January 2012 16:13:48 Thiago Macieira wrote:
> > 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

Of course. My point is that, if we need that functionality, there is no other 
way than to include the STL header. Especially for <typeinfo> and 
<initializer_list>.

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

Right, I'd forgotten about those. The C++ headers have a few more overloads 
that C doesn't, so they are useful. In cstring there are such too.

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

type_traits cannot be completely implemented without compiler help. How to 
implement something like std::is_nothrow_constructible?

But since it's C++11, we can't depend on it. So ABI decisions must be made 
without type_traits. For example, we can't use 
std::is_trivially_copy_assignable and std::is_trivially_move_assignable to 
determine whether a type is movable for QList.

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

In this case, I was thinking of using std::thread and others in the backend, 
hidden behind Qt API, like I did for std::atomic.

> >  - the strings themselves (chapter 21)
> 
> If we do the interpolability we have to use them.

DId you mean interoperability? Because I really do not understand why you'd 
want to interpolate strings...

My point here and below with "the containers themselves" is that we don't want 
to use those containers in our code nor in our API.

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

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

A compiler could break the standard library without breaking the ABI and Qt 
could survive such a change unchanged and not rebuild. This is more true of 
the more complex, non-inline classes than the basic language support (like 
operator new).

In practice, it's not likely to happen and, even if it does, chances are you 
need to recompile anyway just because of the library dependency.

-- 
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/2be55ba3/attachment.sig>