On 25/05/2010 13:00, Thomas Klimpel wrote:
Ok, but we need a tutorial for newcomers that don't care about language issues, just how to make their class movable. > But this tutorial is already part of the current documentation, or do I misunderstand something?
Sorry, I thought you wanted to drop this part. Writing so many conversion operators has consequences ;-)
Regarding containers, I think (please, correctme if I'm wrong) we can only move_assign rvalues in non-optimized mode catching by value. And this is a big pessimization for container copy constructors because the container does not reuse existing resources:
Yes, but the reuse of existing resources is not without drawbacks (independent of the problem with the non-const assignment operator). So I wouldn't object to have the option to use the optimized mode with containers, but the non-optimized mode is more important, so if there has to be a choice, the non-optimized mode should win.
Well, I gently disagree, but maybe you are right and others also prefer the non-optimized mode. We'll come back to this issue if someday we review Boost.Container ;-)
The problem is what should generic algorithms should expect from a class, because for an object in non-optimized mode, assignment from a rvalue might not by the best way to implement an algorithm, but the algorithm does not know that (and even this has consequences with exception guarantees, but this is another issue).
Yes, this is an interesting question. In my opinion, breaking move assignment from temporaries is worse than not reusing existing resources, so for me the non-optimized mode is the one that catches by value for BOOST_COPYABLE_AND_MOVABLE classes.
Got it. If there is no stronger reason, this approach has no surprises, but I don't know if that would be the way programmers would write C++0x code (I mean, catching by value will be more common than by reference?) Best, Ion