[Development] Question about QCoreApplicationData::*_libpaths

Marc Mutz marc.mutz at kdab.com
Mon Jan 18 23:11:14 CET 2016


On Monday 18 January 2016 19:06:36 Matthew Woehlke wrote:
> On 2016-01-18 12:47, Giuseppe D'Angelo wrote:
> > On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke 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...
> 
> Riiiight...
> 
> > that's what you get when you have a value type with
> > reference semantics, such as all the CoW types you find in Qt.
> 
> Again, no? How does a container contain a pointer to a data segment?
> Heap, yes. Stack, maybe. Data segment? No. How does "reference" suddenly
> magically equate to "reference to data segment"?
> 
> >> At least, last I checked, Qt containers cannot live in program data
> >> segments.
> > 
> > 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
> 
> I honestly have *no* idea what you are talking about. CoW means shared
> ownership. If a module holding a reference to some container goes away
> while the main program also holds a reference, then... the module
> reference goes away and the main program is left with one fewer shared
> reference. Where is the problem?

QString foo() { return QStringLiteral("foo"); }
QString bar() { return Q3DeepCopy<QString>(QStringLiteral("foo")); }

You will _never_ have the plugin-unloading problem with 'bar', only with 
'foo', and the reason is CoW: suggesting value semantics where there aren't 
any.


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



More information about the Development mailing list