Boost logo

Boost :

Subject: Re: [boost] [contract] move operations and class invariants
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-11-30 03:40:20

On 30/11/2017 11:45, I wrote:
> To put it another way, if you move-assign a vector to another vector, it
> is perfectly legal for the source vector to not be empty afterwards.
> (For example, instead of a destroy-and-swap it could be implemented as a
> pure swap.  Or even as a copy, although that's less likely with modern
> STLs.)
> (At this point language lawyers might jump on me that vector does
> actually provide somewhat more specific guarantees about how move-assign
> behaves.  But the point stands for generic types.)

Donning my own language-lawyer hat for a moment: there are actually some
cases where a modern STL is actually *required* to implement a
move-assign like a copy-assign -- notably when containing a type that
has a custom copy-constructor without a custom move-constructor and
using a non-propagate_on_container_move_assignment allocator which
doesn't compare equal.

Perhaps this can be argued to be a niche case, but it would indeed be a
case where the source vector isn't empty afterwards, thus requiring the

Boost list run by bdawes at, gregod at, cpdaniel at, john at