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

[Giuseppe D'Angelo]

Howdy,

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

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 
15+ years?)

>> Option 2:
>> Create new Qt containers to have the same complexity as Standard Library
>> containers, but following the Qt naming conventions. Possibly with implicit
>> sharing.

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

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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160701/465658fb/attachment.bin>