[Development] Question about QCoreApplicationData::*_libpaths

[Giuseppe D'Angelo]

On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke <mwoehlke.floss at gmail.com>
wrote:

> 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.)
>

QStringLiteral is *exactly* a pointer to an object (QStringData) living in
a data segment... that's what you get when you have a value type with
reference semantics, such as all the CoW types you find in Qt.


>
> 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.)
>

How you do you get a hold on them? Because if you have a
reference/pointer/smart/weak pointer to them, then you immediately see the
problem of ownership. If you have a value, you don't see it, and kaboom


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


That's not the point, the point is that atomic operations still add their
hidden costs everywhere (which you pay all the time) and scale less
efficiently (because now we have multi core systems and these atomic
operations trigger barriers which are expensive), than reasoning on the
ownership of a data structure and actually copying it only when it's
absolutely needed. And note that if you're willing to pay the price of the
convenient you can always create a "shared version" of an "unshared
container" (shared_ptr<vector<Foo>>, etc.), but you can't remove CoW from
Qt :\

Cheers,
-- 
Giuseppe D'Angelo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160118/f6d311a2/attachment.html>