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

[Smith Martin]

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

The suggestion was not to discuss everything about C++ efficiency but to discuss the traps for young players using a QMap when a sorted QVector would be better.

>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]

But if this is a new world, then the CS course and reference books you suggested might not say much about it yet.

I'll bet most of our customers are not the C++ equivalents of Bruce Lee you imagine them to be. Some of them might be coming to C++ via trying to create something in QML.

martin


________________________________________
From: marc at kdab.com <marc at kdab.com> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Tuesday, February 10, 2015 10:51 AM
To: Ziller Eike
Cc: Smith Martin; development at qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

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