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.m...@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.m...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
