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