[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Saturday 16 January 2016 01:29:40 Kevin Kofler wrote:
> Now, what I find "simply *not acceptable*" is that "a seemingly innocuous 
> piece of code like":
> std::vector<Foo> foo1 = …;
> std::vector<Foo> foo2 = foo1; // <- here
> "leads to a memory allocation, nay, a complete deep copy of the
> container".  This is particularly problematic when you want to have
> methods that return an STL container, because returning a reference is a
> bad idea. (Of course you can return a pointer, but that opens its own can
> of worms, plenty of ways to shoot yourself in the foot there: the same
> issues with explicit sharing semantics as in Java, plus memory leaks and
> more.)

It's perfectly acceptable, because that is what C++ defaults to. If you return 
a struct containing 10 ints, you get those 10 ints copied. If you don't want 
that, you return some form of reference (&, const-&, std::reference_wrapper, 
shared_ptr, ...). Why should a vector (or a QPen, even) behave differently? You 
can always add reference semantics to a value type (e.g. by forming a 
shared_ptr to it), but never the other way around. It follows that C++ types 
should have proper value semantics, so users can selectively add reference 
semantics _where needed_.

The same issue applies to Q_FOREACH. It, too, by default copies the container. 
You never know whether that copy is necessary. It makes it harder to reason 
about the code. If I see a range-for, or a classical iterator-based for-loop, 
I know that the container cannot possibly be modified while iterating, unless I 
see it in the for loop body directly, adjusting the iterator, and then it's 
almost always a performance bug (a big-O one!). Always using Q_FOREACH makes 
it very hard to see what's going on.

Another argument against CoW is that it creates non-local dependencies. In 
that, it's like having global variables. With pretty much the same problems, 
cf. the QStringLiteral-in-unloaded-plugins problems.

Not to mention that the rest of the world is quickly moving away from CoW, 
everywhere, because it's no longer an optimisation in today's multi-core 
world. Only Qt knows better.  The hubris of it!

And please don't forget that I'm here always talking about the Qt 
implementation. You can do in your projects whatever you want. In Qt, the 
taking of such liberties equals a profound ignorance of our user's needs.

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