Menu
Is a shared memory/copy on write implementation for general containers (like that found in Qt's containers) superseded by C++11 move semantics and rvalue references?
Where does one fail and the other succeed? Or are they complementary rather than alternatives?
853
Move semantics allows you to avoid unnecessary copies when working with temporary objects that are about to evaporate, and whose resources can safely be taken from that temporary object and used by another.
“l-value” refers to a memory location that identifies an object. “r-value” refers to the data value that is stored at some address in memory. References in C++ are nothing but the alternative to the already existing variable.
Rvalue references is a small technical extension to the C++ language. Rvalue references allow programmers to avoid logically unnecessary copying and to provide perfect forwarding functions. They are primarily meant to aid in the design of higer performance and more robust libraries.
std::move is used to indicate that an object t may be "moved from", i.e. allowing the efficient transfer of resources from t to another object. In particular, std::move produces an xvalue expression that identifies its argument t . It is exactly equivalent to a static_cast to an rvalue reference type.
Both copy on write and move semantics have been used to optimize value semantics of objects that hold their data on the heap. std::string, for example has been implemented both as a copy-on-write object, and as a move-enabled object.
So copy-on-write and move semantics is similar in that regard: they can both be used to optimize "copies" if you define "copy" loosely enough. I've sometimes described move semantics as copy-on-write with the reference count being limited to 0 or 1, and thus the field containing the reference count is optimized away.
All of the containers in the std::lib now use move semantics and even std::string, which used to be allowed to use copy-on-write, is now forbidden from doing so. If I were writing a new customer container today, I would use move semantics before choosing copy-on-write.
There is still a use for copy-on-write in C++11. If you expect your data structure to be rarely written to, but copied often, with many clients holding copies of the same value, copy-on-write can still be a large win.
For example I've seen copy-on-write put to good use to hold an undo-list for a complex document. At any given commit (where you want to save state), only a small piece of the large document has changed since the last commit. So making a copy of the document to save its state means updating a bunch of reference counts, and actually making changes (copy-on-write style) to a small piece.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
