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 -> constFindOf 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.dang...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
