Subject: Re: [boost] [Review] Formal Review: Boost.Move
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2010-05-25 07:31:30
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