[Development] Use of Standard Library containers in Qt source code

[Thiago Macieira]

On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> Even today: where is QList::push_back(T&&)? Where are our emplacement
> functions and their try versions? Where are our exception guarantees?)

We don't care about exceptions, so we won't be adding those.

As for the move-versions, since we can't take move-only types in our 
containers due to the implicit sharing, does it really make a difference if we 
have them or not?

> >> Option 3:
> >> Create Qt API wrappers for those containers like std::deque, adding only
> >> a
> >> few  inline functions to match the Qt-style API where the Standard
> >> Library
> >> 
> >> API deviates. Examples are:
> >>          empty           ->      isEmpty
> >>          push_back       ->      append
> >>          front           ->      first
> >>          pop_front       ->      takeFirst
> >>          cbegin          ->      constBegin
> >>          cfind           ->      constFind
> > 
> > Of course, Option 4:
> > Continue to allow Standard Library containers in internal code (no API or
> > ABI constraining) where there's a clear gain in performance and/or size.
> 3 and 4 actually don't conflict, do they? If we subclass STL containers
> (say, in a QtStl namespace) and add those inline functions we would
> still be using them in the end. But before going this way, is it
> possible to estimate the amount of work to get this in place?

The difference is the API used elsewhere in our code.

The amount of work should be minimal. There's just a handful of functions that 
need different names, plus two more like takeFirst and takeLast that do two 
things in one.

> > Option 5:
> > Allow Standard Library containers in internal code even if performance or
> > code size gains are not appreciable or have not been measured.
> 
> Which again seems like a sensible thing to do in general, unless there
> are documented cases in which Qt containers significantly outperform STL
> ones (apart from implicit sharing).

I would prefer the opposite: use non-Qt only if that is better than the Qt 
equivalent. If you can't prove it or if it's too small, it's not worth the 
difference in readability that it creates.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center