[Development] Question about QCoreApplicationData::*_libpaths

[Matthew Woehlke]

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?

String literals (whether QStringLiteral or char const*) are a problem
because the *actual data* lives in a module data segment. It is not
(currently) possible for a Qt container's internal state to be stored in
a data segment. (If it ever becomes possible, it will almost certainly
be possible for STL containers *first*.)

Maybe you are trying to argue a completely different point? Yes, CoW can
muddy the waters ownership-wise. I'm not saying there aren't drawbacks.
What I *am* saying is that it does NOT do is cause your program to crash
because the module that originally created a container which is now
shared has been unloaded. That is, I am specifically objecting to the
statement that CoW has "the same problems [as]
QStringLiteral-in-unloaded-plugins". It doesn't. The problem with
QStringLiteral in unloaded plugins is totally different and is not an
inherent problem with CoW. Accordingly, that statement is a gross and
unfair misrepresentation.

-- 
Matthew