3

The Standard library containers in C++ have constructors that take iterator ranges. This is handy when the content of an input container is convertible to, but not the same as the content in the resulting container, or even if the container is just different. The constructor overload allows for this type of conversion to happen in a surrounding class's constructor, which leads to less clutter in the code.

So the question arises, why don't the Qt containers have this overload? Is it an oversight or is there a reason behind this clunky design choice?

rubenvb
  • 74,642
  • 33
  • 187
  • 332

2 Answers2

7

There is no reason except for "nobody implemented them so far", as the Qt Project doesn't have an infinite development bandwidth.

Speaking of such missing features, you could say the same for:

  • the fact that you can't store move-only types in Qt containers due to implicit sharing;
  • the lack emplacement functions (and their upcoming try versions for associative containers);
  • the lack of rvalue-overloaded functions (no QList::push_back(T &&));
  • QList having no equivalent in the STL and being a very strange monster with serious performance issues. It is now acknowledged that it should have never been made the "good generic container" used everywhere in Qt;
  • no exception safety guarantees whatsoever;

and so on.

There's lots of discussion going on these days (f.i. see this thread) about the poor state of Qt containers when compared to the STL ones, to the point that we're starting using STL containers in Qt's own implementation.

Unless you have specific reasons for using the Qt ones (say, you need to pass them to Qt-ish APIs, or you like/need implicit sharing, etc.), these days STL containers are way better than Qt ones.

Update: QList in Qt 6 is going to be a proper vector, and QVector (In Qt 6) will be an alias to QList. Some of the remarks above will not apply any more. I'm not modifying the rest of the answer as that still applies to Qt 5.15.

peppe
  • 21,934
  • 4
  • 55
  • 70
  • 1
    The first three can be blamed on C++11 not being integrated yet (that really only started happening in Qt 5.7. The exception safety, well, yeah, I guess they took the easy road of telling themselves "there are no exceptions". The STL iterator range constructor has been there for, well, ever. – rubenvb Jul 08 '16 at 09:44
  • 1
    That's not the entire story. In 5.7 a C++11 compiler was made mandatory, but Qt had (conditional) support for C++11 constructs since 5.0. They were just `#ifdef`'d in the code. Still support for move-only types is botched by design: any container's `operator[]` will need to emit code that detaches if the refcount is greater than one, and detaching requires an available copy constructor. By the way, you can say the same "forever" about exception support, no need of mandate public default constructors, etcetera. – peppe Jul 08 '16 at 10:12
  • Ah, ok. Well, too bad. Cause Qt really has got a lot of useful features and I don't think there's a framework with the same scale and (other than these issues) quality of implementation... – rubenvb Jul 08 '16 at 10:36
  • To actually add insult to injury: why in the world somebody thought of adding `QList QVector::toList()`, instead of a ranged constructor? – peppe Jul 08 '16 at 14:13
  • "the fact that you can't store move-only types in Qt containers due to implicit sharing;" why does implicit-sharing prevent move-only types? It seems to me that such containers would never be implicitly-shared, so we never would need to "copy-away"/detach containers. Can you please elaborate? – Johannes Schaub - litb Oct 13 '16 at 14:35
  • @JohannesSchaub-litb: I would actually need to amend the previous comment, but apparently I can't... You're right, it does not prevent it per-se, it just makes the code way more complicated than it should be. The containers would "just" need some `enable_if` around to disable the copy operations, and possibly provide alternative implementations of all the non-const operations (to make them not even emit the code for detach(), which IIRC in some containers is in non-templated code...). Given the little love Qt containers have received in the last few years, why not just going for the STD? – peppe Oct 13 '16 at 15:58
  • @peppe because i have used QList everywhere and it's "the list type" in qt. if it's supposed to go away or be deprecated, then maybe i would change. But is there no hope to give it a little love again? – Johannes Schaub - litb Oct 13 '16 at 16:01
0

There are several features of STL containers lacking in Qt containers. You can find a great review of them in blog of Marc Mutz here.

To my opinion, the plan was to replace the feature of taking with iterator ranges in construction with qCopy, http://doc.qt.io/qt-4.8/qtalgorithms.html. In Qt 5 many iterator and const_iterator features for containters appeared in Qt and probably appropriate constructors for QList and QVector may also appear in later versions (not announced, just a thought).

demonplus
  • 5,613
  • 12
  • 49
  • 68