[Development] Question about QCoreApplicationData::*_libpaths

[Matthew Woehlke]

On 2016-01-17 07:55, Marc Mutz wrote:
> 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.

Ah... no? The problem with QStringLiteral is that it forms a reference
to a module *data segment* which can potentially go away. CoW does no
such thing. (I don't consider the case of containing pointers to objects
in a data segment; that's the fault of the item type, not the container
itself, and STL containers would have the exact same problem in such a
case.)

At least, last I checked, Qt containers cannot live in program data
segments. (I do acknowledge there have been some mutterings about
constexpr STL containers, which presumably could thus live in data
segments. AFAIK there isn't the requisite constexpr memory allocation
yet, though.)

> 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!

I still haven't figured out how deep-copy of megabytes of memory and/or
hundreds of complex copy ctor invocations is supposed to outperform a
single atomic operation... Even on modern architectures.

Sure, CoW for a few dozen or maybe even hundred bytes, with trivial copy
ctors, may be a loss. I don't buy that it's a loss in all cases, however.

-- 
Matthew