On 08/02/13 18:41, Ralph Tandetzky wrote:
Copy-on-write is the most important use case of the class design. Even larger libraries like Qt use copy-on-write for some types (like QImage or QPixmap) and make the user interface much easier to use.
That's because Qt is broken, and is written to support broken C++ programming practices. If you only copy when you need to copy, then there is no need for the COW mechanism. COW was invented to workaround issues with code that copied but didn't actually need to. COW also has the nasty effect that your real object is gonna change its address just because you modified it. For this reason the C++11 standard prevents implementation of standard components like std::string from using that mechanism.
A major reason is that value semantics are easier to reason about than reference semantics. For this purpose cow_ptr<T> is an enabler. Moving isn't always sufficient.
Value semantics do not require COW. There is no logic between your statements. Value semantics mean that when you modify a copy of an object, then the original is left unmodified. To achieve this you can either copy when requested or delay it until you're actually modifying. The simplest way to deal with this is to simply copy when asked to copy by the user, which is not only straightforward and keeping a good separation of concerns, but it also means you don't need the delaying mechanism and the overhead attached to it. KISS.
The class design allows you to copy objects polymorphically. I tried it. It works. It's useful.
It would work just as well without COW. COW does not affect observable behaviour, it's purely an implementation-specific detail. It should not leak in the interface.
I used it in production code.
That just means the code does what you need and is stable enough to work reliably in your use cases. This doesn't say anything about the quality of the design.