[Development] Question about QCoreApplicationData::*_libpaths
marc.mutz at kdab.com
Tue Jan 19 15:00:33 CET 2016
On Tuesday 19 January 2016 12:53:35 André Somers wrote:
> Op 19/01/2016 om 13:15 schreef Marc Mutz:
> > On Tuesday 19 January 2016 11:13:16 Harri Porten wrote:
> >> On Tue, 19 Jan 2016, Marc Mutz wrote:
> >>>> I think we agree that std containers are in many cases faster than the
> >>>> Qt containers. But they are harder to use and especially developers
> >>>> that come from other languages often appreciate the ease of use of the
> >>>> Qt containers.
> >>> I always cringe when I hear this. What, specifically, do you mean by
> >>> "easier to use"?
> >>> No-one, not even experts understand QList, really. So it may appear to
> >>> be easy to use, but is actually a container only absolute experst
> >>> should use.
> >> What kind of 'understanding' are you expecting? I'd say that every Qt
> >> beginner, the biggest greenhorns, 'understand' absolutely enough to use
> >> the class. And yes: that view might be incomplete and non-optimal in
> >> regards to performance or in some extreme cases.
> >> finds such Qt classes documented next to the others. And appreciates
> >> e.g. a consistent API style. You may not personally like it but this
> >> individual matter of tastes cannot be fully fulfilled in a project with
> >> that many contributors and users.
> > I was referring to the fact that references into the container either do
> > get invalidated upon, say, appending, or they are not, depending on the
> > memory layout. That is a very important (to know about, not to have)
> > property of a container. One that should be either true or false, and
> > not, as for QList, depend on, among other things, the processor's word
> > width. ETOOSUBTLE.
> Yet many developers, even green ones, have managed to write some pretty
> nice software using the container.
And the same is true for std::vector.
> Perhaps that feature is not used as
> much as you think it is? Or only by people who actually understand the
> class at your level of understanding or something close to it, while for
> all others it works just fine?
My point is that the Qt containers try to "fix" easy-to-understand, local
problems (iterator invalidation, deep copies) of the std containers with hard-
to-understand, non-local ones (Q_FOREACH, QList, CoW with its problems:
iterators into shared containers, hidden detaches, move-only types). That
doesn't help the programmer. It flattens the learning curve in the beginning,
sure, but leads to a very high learning curve at the intermediate level. All
the while providing the same API as the STL containers, meaning many of the
problems come back, too, like iterator invalidation.
> I am not denying that there are issues with the Qt containers, and with
> QList in particular. I think you made some very valid points on that
> front. I just wonder if the problem is really so big that it needs
> taking down the complete Qt container library and the massive source
> breakage that will cause.
And I'm wondering: with TQC not investing in the containers, at some point
will they bit-rot to smithereens? C++ now provides the means to ease the
1. Tell people to use auto when receiving Qt containers returned from a
2. Tell people to stick to the std-compatible API subset.
3. Deprecate Q_FOREACH and recommend range-for (+ qAsConst(), where needed).
In Qt 6:
1. Implement the containers on top of std ones, dropping CoW, providing
simple, fast (when moving), conversion between std and Qt containers.
2. Deprecate the std-incompatible API subset
3. Remove Q_FOREACH
4. Deprecate qAsConst()
In Qt 7:
1. Drop all Qt container API use from the library, use only std ones.
2. Keep the Qt ones around as deprecated, in a separate compat library.
3. Drop qAsConst()
In Qt 8:
Remove the Qt ones.
That easily spans 10-15 years, but at least we'd have an exit strategy.
If, otoh, by Qt 6, we'd still continue doing nothing, as before, we'll lose
another four years.
> > The STL also has a consistent API style. But that wasn't my point here.
> > But since you've mentioned it: no, I definitely don't see a need for
> > first() and last() if there's front() and back(). Or count() instead of
> > size(). Actually, count() is against Qt API design guidelines, because
> > it is also a verb, and nothing is counted here. That would be an O(N)
> > operation.
> > And if API consistency makes QVector have a prepend(), and
> > QHash::iterator have it + n, something got out of hand...
> Why shouldn't QVector have a prepend? Because it is not very fast to do
s/not very fast/prohibitively expensive/
You can always say v.insert(v.begin(), e) if you really, really, want to. But
the STL carefully does not provide inefficient operations. In a way, that's more
user-friendly than the "convenience" of QVector::prepend().
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt Experts
More information about the Development