[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

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.
> >> 
> >> And anyone coming from a Java, JavaScript or whatever background easily
> >> 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 
transition:

Now:
1. Tell people to use auto when receiving Qt containers returned from a 
function.
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
> that?

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

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts