[Development] Question about QCoreApplicationData::*_libpaths

[Bo Thorsen]

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