[Development] Question about QCoreApplicationData::*_libpaths
Marc Mutz
marc.mutz at kdab.com
Tue Jan 19 13:15:18 CET 2016
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.
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...
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
More information about the Development
mailing list