Boost logo

Boost :

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])
> 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

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