Re: [boost] move semantics

From: brangdon_at_[hidden]
Date: 2002-03-12 16:04:18

In-Reply-To: <F2A65FA5-3548-11D6-AF90-003065D18932_at_[hidden]>
On Mon, 11 Mar 2002 18:37:27 -0500 Howard Hinnant (hinnant_at_[hidden]) 
wrote:
> And of course ~Base() and ~Derived() would tell their respective 
> listeners that they were being destructed.  For example:

Suppose these lists of listeners are stored in something like a 
std::vector - in some container which owns memory and cannot have a 
no-throw copy. So the list must be moved or transferred when Base is moved 
or transferred. (Even if Base does not use a vector, Derived probably 
shouldn't rely on the fact.)

> Non-destructive move is tons simpler than this.
> 
> Derived(move from x)
>       : Base(move from x), client_(x.client_), owns_(x.owns_)
> {
>      notify_construction();
>      x.owns_ = 0;
> }

But what happens when the source is eventually destroyed? The destructor 
will call notify_destruction(), and this routine will find an empty, 
resourceless list. The notification will be lost. Listeners will see 2 
constructions but only 1 destruction. Chaos reigns.

OK, it's not as bad as undefined behaviour, but it's not good, either. No 
doubt we can find examples where move works and relocate doesn't, but that 
doesn't mean move is intrinsically safe. The mine-field still lurks. Moved 
objects should do no real work in their destructors. It should be done in 
the move-constructor instead, just as for relocation.

Although I share your unease, I don't think it is a killer argument 
against relocation.

-- Dave Harris