[Development] Use of Standard Library containers in Qt source code
giuseppe.dangelo at kdab.com
Fri Jul 1 22:13:42 CEST 2016
Il 01/07/2016 21:34, Thiago Macieira ha scritto:
> On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
>> Option 1:
>> Not use Standard Library containers, just use the Qt containers as they
However this is an anti-goal. As you stated, STL containers usage inside
Qt is increasing for very good reasons. In the case in question, there
isn't even a Qt equivalent for std::deque, and I don't see one coming
anytime soon. (And even so, is it really going to outperform a container
which has been around, studied, profiled, optimized, instrumented, for
>> Option 2:
>> Create new Qt containers to have the same complexity as Standard Library
>> containers, but following the Qt naming conventions. Possibly with implicit
Again, also this looks like a massive anti-goal. I don't think we should
invest any resource in this massive effort that reinvents the wheel,
just for the sake of renaming a few functions.
(... not to mention that is extremely likely that we will always lag
behind the current Standard and perform worse than any other STL
implementation under any possible benchmark.
Even today: where is QList::push_back(T&&)? Where are our emplacement
functions and their try versions? Where are our exception guarantees?)
>> 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?
> 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).
IIRC, when there was the big thread about whether allowing STL
containers or not in Qt implementation, people did such benchmarks and
the results were always in favour of STL. Can anyone find the relative
My 2 cents,
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4007 bytes
Desc: Firma crittografica S/MIME
More information about the Development