[Development] Question about QCoreApplicationData::*_libpaths
kevin.kofler at chello.at
Sat Jan 16 00:44:22 CET 2016
Marc Mutz wrote:
> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
>> So why not just add a QOptional that works the same as std::optional?
> a) because we can't (we don't yet require the necessary language features)
A QOptional<T> that works with Qt's implicitly-shared data objects (such as
QStringList, which is what it is wanted for here) only really needs this:
(I guess that order will give the better memory layout than the opposite
order.) If present is false, you just put a default-constructed T into the
(ignored) data field, which will simply have a null d-pointer and thus cost
you almost no time to construct. I don't see what further language features
are needed for us.
> b) because once introduced, people will add all kinds of Qt-specific stuff
> to it, making it impossible to replace it with std::optional down the
> road. And since it will be good enough for the low demands of Qt
> development, it will no longer see development and fall behind the state
> of the art.
So what? Qt users are not forced to use it, and I'm sure several will, maybe
BECAUSE of the "all kinds of Qt-specific stuff" that people actually find
> Consider QVector: it has been Qt-ifed by both adding (technically) useless
> duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme
> plus corresponding optimisations that make it very hard to argue for
> std::vector use instead. The Qt community had two decades where they could
> have influenced the direction std::vector would take so it could allow the
> same optimisations that QVector has, but the time and energy was instead
> put into re-writing the containers for every major release (yes, for Qt 5,
> too, and Thiago's Qt 6 QVector again looks much different from the Qt 5
But the Qt-ish API and the CoW are exactly what makes the Qt containers NICE
to use, unlike the STL. I have found myself more than once using QtCore in a
project solely and explicitly for the container classes! They are what makes
C++ a nice-to-use language.
> The CoW makes QVector slow and increase code size, leads to hidden
> detaches that not even Qt experts regularly avoid in their daily work, and
Well, I am well aware of the issue, and know to use e.g.:
static_cast<const QVector &>(vec).first()
when needed. (I guess this is actually more efficient than the popular
.at(0) workaround. It is definitely not less efficient.) But normally I will
just always operate on const data structures (usually const references) when
I'm not writing to them, so I don't have to cast anything. (And of course,
when I'm writing to them, chances are the detach is exactly what I want or
> doesn't even work properly because you can take iterators into a QVector
> and, after copying the vector, change both copies through the iterator
> into the first. That is a conscious trade-off because making the container
> unsharable, as it must become once it hands out iterators, would make CoW
> fail to take effect _all the time_. But it leads to careless copying of
> QVectors that also doesn't really help with porting to std::vector.
So don't use iterators into QVector, use indexes, it's a random-access
container. The non-const operator that you use then DOES detach when
needed. (And of course, for read-only iteration, foreach works great.)
The only container type where I found iterators to be truly useful is maps
(QMap, QHash, etc.), where the iterator can give me both key and value at
once and saves me the key lookup.
> All the while - and I don't believe I'm saying this - std::vector *blazes
> the trail* with move semantics, emplace_back and stateful allocators
> (making QVarLengthArray all but useless). Does QVector use move semantics?
Move semantics are mainly an ugly way to avoid copies if you don't have CoW.
With CoW data structures, all you save through move semantics is the
reference counting. And move semantics make it easy to shoot yourself in the
foot. (Either you leave behind an invitation for a use-after-free bug, or
you end up swapping instead of assigning, which is also a pessimization.)
> Does QVector have emplace_back? No.
Just like the move semantics, this is also an ugly and complicated way to
avoid a copy if you don't have CoW or merely save the reference counting if
> Does QVector have an allocator, even one that, citing Alexandrescu,
> actually deals with allocation? No.
For the average programmer, an allocator is just an obscure thing that shows
up as a template parameter in all the error messages making them ugly and
The fact that Qt containers only have the template arguments that are
intuitively templated on (e.g., QVector has only the contained type as a
template parameter) is really a feature, not a bug.
> Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as
> std::vector? No: https://codereview.qt-project.org/145587 (comment from
> 01-14 11:21).
So there is room for improvement there. But in the end, this is not going to
be the deciding factor for which implementation to pick for most
programmers. And in the end, you need to compare QVector with class
libraries in programming languages that offer comparable convenience, not
with the C++ STL.
If you try to force programmers to use the STL, chances are they will rather
just switch to some other programming language that offers the semantics
> Does QVector have a debug mode comparable to that of std::vector
> implementations? Nope.
I never had any need for that.
> Or: The only reason I ever used std::list was to use its splice() feature.
> Does QLinkedList have splice()? No, of course not. Because it _cannot_
> (it's CoWed: how do you take ownership of nodes if the they are shared? By
> copying all other nodes in a detach()?).
Then use std::list if it suits your use case better. Just don't force
everyone else to use it.
Personally, I also don't normally have a use for QLinkedList, QList suits my
needs just fine. :-p (In fact, QList was changed from the linked list it was
in Qt 3 to an array of pointers in Qt 4 exactly BECAUSE that's the more
efficient data structure in most practical applications.)
And I simply find the Qt containers to be much nicer to work with as a
whole. In fact, I recently had to use std::priority_queue for a (QtCore-
based) project of mine, a container class that sadly is not implemented in
Qt (*). After attempting to use it directly and cursing about it, I ended up
implementing a Qt-style wrapper around it:
* My data class simply multiple-inherits from public QSharedData,
* My public class contains a QSharedDataPointer of the above, renames the
methods to names matching QQueue, and in particular adds a dequeue()
method that does both top() and pop(). Null objects (null d-pointer) are
also handled gracefully (the const methods fake an empty queue, the
enqueue (= STL push) method allocates the d-pointer).
So, a few lines of boilerplate, and suddenly the API becomes usable, and CoW
just works. Incidentally, the CoW was also the only way I found to avoid a
copy of the whole queue while initializing while keeping C++98 compatibility
(so no move or swap):
* I need to initialize my priority_queue from a list (actually a QList :-)
but I would have the same issue with QVector or even std::vector).
* There is no push method that takes a whole list of items.
* So I can only:
- either push every item one at a time, which sorts them less efficiently
than a bulk insert,
- or use the constructor that takes iterators, which then leaves me with a
whole std::priority_queue to copy. My CoW wrapper avoids that copy.
* And my API wrapper actually accepts the QList (or actually any list type
with constBegin() and constEnd() methods) directly instead of requiring
(*) I did find one third-party QPriorityQueue class, but it was just a
wrapper around std::priority_queue that was neither CoW nor had API
consistency with QQueue, so it was better to implement my own.
> This is why we need to stop duplicating std API. It's not Qt's core
> competency to meddle with things we only have a half-interest in. It's fun
> to write QOptional. Until it isn't anymore. And then the (Qt) world needs
> to live with the poor-man's std::optional for the next few decades.
I think having more Qt containers would actually be a good thing, not
something to be scared of.
More information about the Development