Le samedi 05 mars 2011 à 12:07 +0000, Christopher Jefferson a écrit :
On 5 Mar 2011, at 12:04, Ivan Le Lann wrote:
The opposite view also stands: Move will benefit to most C++ classes/functions while only those who have designed their classes to use COW can afford not to use Move. Designing a COW class is more complex than a Move enabled one.
My KISS understanding of move is that it's telling me: use functional programming style, so that you don't need std::move. Of course, this is not always possible, but I think that this limits the scope of your (valid) point.
You seem to be saying that COW makes things harder on the implementor, but easier on the user (as they do not have to use either std::move, or carefully designed coding methods)
I only considered coding style here and from that point of view, yes, though I would not have said easier but more lenient. Unless using auto&& which can break your code just like auto_ptr did, just naming a variable prevents move. Many people use named variables for documentation and code readability. Thus I dare to say that move is "coding style touchy". Going further, the user also has to consider delivered service in terms of performance and thread safety. It seems there is a concensus against COW. I have no idea on this. I trust benchmarks and smart guys, and my intuition that simpler things are better. As I said, I consider move simpler. Having said that, we (and me first) should stop opposing COW and Move. Move is here and works at a different level. It even minimizes COW flaws. So it's not about "COW or Move?". It's about "To copy or not to copy?". I guess some people here want a C++ where you have to call std::copy to invoke a copy constructor. :-) Ivan