[Development] Question about QCoreApplicationData::*_libpaths

[Иван Комиссаров]

I've already heard those arguments, however we _can't_ use std::vector in
API, because it's implementation may differ between compliers (gcc and
clang stdlibs, for example).
But we can use some features that implemented in the same way (std::pair or
std::exception).
You can continue to say how bad QVector is (and it is) but it will not be
thrown away in near future.
Same is for std::optional. Are they compatible between clang and gcc? (and
between different versions of gcc (std::unordered_map was not))

2016-01-15 14:20 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160115/e702a580/attachment.html>