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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk