[Development] Question about QCoreApplicationData::*_libpaths
Marc Mutz
marc.mutz at kdab.com
Fri Jan 15 12:20:27 CET 2016
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
More information about the Development
mailing list