[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Marc Mutz]

On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
> > On Feb 9, 2015, at 3:40 PM, Marc Mutz <marc.mutz at kdab.com> wrote:
> > 
> > On Monday 09 February 2015 09:54:12 Smith Martin wrote:
> >> This is the kind of thing we should add to the documentation, but can
> >> you elaborate? I mean, illustrate the meaning of "locality of
> >> reference," "wildly mixing insertions, lookups, and removals," and
> >> "batch updates and separate them from lookups, time-wise."
> > 
> > There is a book, Effective STL, and an online paper, "What every
> > programmer needs to know about memory". I don't think that it's the job
> > of the Qt docs to explain "what every programmer needs to know about
> > memory", because it is not specific to Qt.
> > 
> > The Qt documentation also doesn't give many details on Unicode. It's
> > assumed that people using it know the basics.
> > 
> > You will also not find in the Qt docs that signed integer overflow is
> > undefined behaviour.
> > 
> > The Qt docs are not a CS text book :)
> 
> That QMap is implemented based on a RB tree is mentioned in a single
> sentence in the beginning of the description of the class, which is the
> sentence that nobody ever reads (because it tends to contain useful
> information like "The QList class is a template class that provides
> lists.”).
> 
> It is followed by a short (but longer) comparison between QMap and QHash,
> which in turn is linked to a relatively long section that compares the
> complexity of Qt’s different containers. So, fact is that the Qt docs *do*
> explain more than “QMap is a RB tree” (and I think that is good so). And
> since they talk a lot about algorithmic complexity, it would probably be
> useful to mention a few other things that concern performance differences
> as well. In ~5 sentences. I really can’t see how that could hurt.
> 
> Actually you sounded like you’d like to educate people about this also
> “outside of CS courses” (by sending them to their manager etc), so do you
> have a different, realistic proposal?

The topic of this thread is guidelines for Qt code, not code using Qt. We 
don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users of 
Qt. Likewise, if they want to use QMap, then that's fine. A profiler will tell 
them if they made a mistake that matters.

The situation is different for Qt code:

Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a 
QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A 
very naïve benchmark (I'm allowed to say that, it was my choice). was sped up 
by 30%. The naïviteé in the benchmark is that this includes repeated 
allocation of a handful of QString arguments from short (C) string literals 
each time through the loop, which probably dominates the result.

We don't know what Qt is being used for, so we need to optimize everything. 
One user surely will run multiArg() in a tight loop and that will dominate his 
runtime. As every C++ library that's any good, we cannot be sloppy when it 
comes to efficiency.

So, no, I don't think we should discuss everthing ever written about C++ 
efficiency in the Qt docs. But we need to point it out to each other in code 
reviews and become better at not writing sloppy code.

IOW: We need to start thinking about our algorithms and data structures 
again[1], but this time in the new world of caches and multithreading where 
the only fast data structure is an array.[2]

Thanks,
Marc

[1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-
Computation/dp/0130224189

[2] http://vimeo.com/97337258

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions