Re: [boost] [move] auto-generated operator=

Subject: Re: [boost] [move] auto-generated operator=
From: David Abrahams (dave_at_[hidden])
Date: 2009-09-07 18:40:58

on Thu Sep 03 2009, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

> Jeffrey Hellrung escribió:
>> Hi (again) Ion,
>>
>> I recently ran into the following issue.  I defined a copyable-and-movable class X,
>> and class Y has a member variable of type X and no other member variables.  It thus
>> (apparently) happens that Y's auto-generated operator= takes a non-const reference
>> to Y, which I would guess is generally not desired, or at least an operator=
>> overload taking a const reference to Y should be available.
>
> Yes, I recently got the same issue in Interprocess. The standard says
> that the auto-generated assignment takes non-const argument if any of
> bases or members' assignment is non-const. Since we generated the
> non-const version with Boost.Move, assignment operators are not
> generated with const arguments. In this case the only solution is to
> avoid compiler-generated assignment operator and write an explicit
> one. Copy constructor does not suffer this because we rely on RVO to
> avoid copies.
>
> The fact that you need to add *both* const and non-const is strange,
> in my case, just definining the const version in the higher-level
> class was enough.

:-(

This was a weakness of all earlier approaches that was fixed by Adobe's
library; I *really* do not want to see it broken by Boost.  It's not
always something you can work around.  Consider putting a
movable-and-copyable type in std::pair; now constant pairs can't be
copied, which breaks everything.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com