Re: [boost] Improving the assignment operators of various Boosttypes

Subject: Re: [boost] Improving the assignment operators of various Boosttypes
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-11 10:07:50

on Thu Sep 11 2008, "Niels Dekker - mail address until 2008-12-31" <nd_mail_address_valid_until_2008-12-31-AT-xs4all.nl> wrote:

> David Abrahams wrote:
>>>> In generic code I strongly prefer
>>>>
>>>>    T& operator=(T arg)
>>>>    {
>>>>      swap(*this, arg);
>>>>      return *this;
>>>>    }
>
>> I'm just saying, I guess, that the form using the member
>> forces me to define a swap member even though it's not really needed
>> by generic code.
>
> I think we should stick to the guideline to always have a swap member function
> for a class, whenever the class has a custom free swap function.  Don't you
> agree?

Sorry, but no, I just don't see the point.  It feels like needless
clutter.  Generic code needs a free function that can be found via ADL,
so I would normally make it a friend declared inside the class body.
There's nothing wrong with adding a swap member, but I'd be loathe to
make it a guideline.

> BTW the swap member function offers a C++03 way to "move assign" an rvalue:
>
>  std::vector<int> generate_some_data(void);
>  std::vector<int> my_data;
>  // Move the result into my_data:
>  generate_some_data().swap(my_data);

Well, that's true, but I much prefer:

      assign(my_data) = generate_some_data();

because it better reflects the logical operation.

> Peter Dimov wrote:
>> Incidentally:
>> http://aspn.activestate.com/ASPN/Mail/Message/boost/1140338> "It doesn't compile with Borland C++Builder 4 or BCC 5.5.
>>
>> The next problem was associative_vector's assignment operator.
>> Borland didn't recognise it as one and generated a default.
>> Then it couldn't disambiguate the generated assignment operator
>> and the one supplied. [...]
>>
>> My memory is correct on this one, too. I'm not sure why BCC 5.5.1
>> didn't exhibit the problem in my tests.
>
> Thanks Peter. Maybe it's a C++Builder 4/BCC 5.5 bug that was fixed by BCC 5.5.1.
> :-) Anyway, neither of them are still at the regression pages.  Siliconman runs
> the tests on BCC 5.6.4, 5.8.2, and 5.9.3, while JustSoftwareSolutions does BCC
> 5.8.2.
>
> Thanks Joaquín, for already applying the patch from ticket #2313 to
> multi_index_container::operator=  Things still look fine at the regression page
> <www.boost.org/development/tests/trunk/developer/multi_index.html> but I guess
> we have to wait a few days longer...

Niels: are you planning to pursue tickets for the classes with implicit
assignment operators and the others I mentioned in response to your
original post?

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