[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
> Иван Комиссаров wrote:
> > Still, what about policy not to use std:: classes in Qt API?
> 
> 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)
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.

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

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

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. Does 
QVector have emplace_back? No. Does QVector have an allocator, even one that, 
citing Alexandrescu, actually deals with allocation? No. 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). Does 
QVector have a debug mode comparable to that of std::vector implementations? 
Nope.

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

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.
</rant>

Please, no.

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