Den 15-01-2016 kl. 12:20 skrev Marc Mutz:
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.
We have seen this rant from you several times before.
The way I see it is that I use QVector when I want the implicit sharing,
std::vector when I need speed.
Maybe I have a different focus, but I just don't see the need for raw
speed very often. On embedded applications I'm very sensitive to it, of
course. But on the Windows desktop, I have yet to see an application
where the choice of QVector or std::vector makes any kind of difference
to the user.
Sure, they are there. And there are areas in the model of an application
where we should consider speed always. But for the vast majority of the
lines of code I write, it makes no difference at all. If it doesn't make
a codewise difference, then obviously a faster framework class is better.
However, my customers have developers that are a lot less experienced
than us. And it's my observation that using the Qt classes over the std
classes lead to fewer mistakes and faster applications. It seems much
easier to shoot yourself in the foot with std. I don't know why this is,
it's only what I observe when I look at code written by others.
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.
Now this is where we completely agree, although probably for slightly
different reasons.
I would not mind removing some (maybe even most) of the Qt containers
for Qt 6 or 7 and forcing people to learn the use std instead. Hash,
map, set and linked list would be the first I'd get rid of. And I don't
care for the binary compatibility with different compilers argument -
just stop shipping binary builds on linux and let people with other
compilers on Windows and Mac compile themselves.
But there will be reasons why some of them should be here. Having CoW
containers is very useful sometimes. And this is only about the
containers, I would never support anyone trying to use the horrible
abominations that are std::string or std::wstring. Or the std streams
*shudder*.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
