mwoehlke.floss at gmail.com
Wed Mar 29 16:41:38 CEST 2017
On 2017-03-29 07:26, Marc Mutz wrote:
> That brings us straight back to the fundamental question: Why can the C++
> world at large cope with containers that are not CoW and Qt cannot? The only
> answer I have is "because Qt never tried". And that's the end of it. I have
> pointed to Herb's string measurements from a decade or two ago. I have shown
> that copying a std::vector up to 1K ints is faster than a QVector, when
> hammered by at least two threads.
4 KiB of memory is not very much. What happens if you have larger
objects (say, 100 objects with 96 bytes each)?
What if you have an API that needs value semantics (keep in mind one
benefit of CoW is implicit shared lifetime management) but tend to not
actually modify the "copied" list?
What benchmarks have been done on *real applications*? What were the
> (I just had to review _another_ pimpl'ed class that contained
> nothing but two enums)
...and what happens if at some point in the future that class needs
three enums? Or some other member?
What, exactly, do you find objectionable about PIMPL in "modern C++"? It
can't be that it's inefficient, because performance was never a goal of
>> so I can't pass it by value into slots.
> Why would you want to? No-one does that. People use cref, like for all large
> types. Qt makes sure that a copy is taken only when needed, ie. when the slot
> is in a different thread from the emitter. That is very rare, and people can
> be expected to pass a shared_ptr<vector> instead in these situations.
This (passing lists across thread boundaries in signals/slots) happens
quite a bit in https://github.com/kitware/vivia/. Doing so is a
fundamental part of the data processing architecture of at least two of
the applications there.
Also, explicit sharing borders on premature pessimization. If my slot
needs to modify the data, I have to go out of my way to avoid making an
unnecessary copy. (This argument would be more compelling if C++ had a
More information about the Development