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.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development