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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
