From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-03-12 17:39:58
On Tuesday, March 12, 2002, at 04:04 PM, brangdon_at_[hidden]
> 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
> or transferred. (Even if Base does not use a vector, Derived probably
> shouldn't rely on the fact.)
Base(relocate from x)
listners_(relocate from x.listners_)
Base(move from x)
listners_ = move from x.listners_;
I'm not really seeing too much of an issue either way. I think I may be
missing your point.
>> Non-destructive move is tons simpler than this.
>> Derived(move from x)
>> : Base(move from x), client_(x.client_), owns_(x.owns_)
>> 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.
Nope. ~Dervied() sees a non-null client_ (assuming it was non-null
before the move). Note that the move constructor non-destructively
copied client_ (just a pointer in this example). Then it destructively
copied the owns_ pointer, zeroing the source explicitly. So:
notify_destruction(); // client_->remove(this)
delete owns_; // unnecessary because owns_ is null
I don't see chaos, as long as this resource-less state is a valid state
for Dervied. The client_ listener will see the addition of the new
Derived, and will retain both Derived on its list until one of them is
destructed. The source may not be destructed immediately. Indeed, it
could be the target of another move assign (as in swap).
> Although I share your unease, I don't think it is a killer argument
> against relocation.
I'm not seeing any killer arguments against relocate either. But the
complications (like being careful with lame ducks, and with auto
objects) are enough that it is a tougher sale.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk