[Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

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:
T data;
bool present;
(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 
convenient.

> <rant>
> 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
> one).

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

> 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?
> No.

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 
you do.

> 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 
unreadable.

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 
they expect.

> 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,
  public std::priority_queue<T>.
* 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
  iterators.

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

        Kevin Kofler