Re: [boost] [shared_ptr] dangerous implementation ofmove constructor

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-04-15 11:54:56

What is expected to happen here:

{
  shared_ptr<T> t(something());
  shared_ptr<T> t1(std::move(t));
} // t1 destructor called, t destructor called?

If t gets its destructor called, then it must obviously be in some self-consistent state. For shared_ptr I think this would mean that upon destruction, it deletes 0. 

If the move constructor proposal doesn't say anything about being in a minimally destructible state after being moved, I think it should. Unless of course the destructor for t doesn't get called (which would imply some runtime checks - always).

-----Original Message-----
From: boost-bounces_at_[hidden] on behalf of Howard Hinnant
Sent: Sat 4/14/2007 4:12 PM
To: boost_at_[hidden]
Subject: Re: [boost] [shared_ptr] dangerous implementation ofmove	constructor
 
Fwiw Peter asked me to look at this.  Imho after a move from an  
object it should be in a self-consistent state.  All internal  
invariants should hold.  This answer is purposefully vague, and could  
be used to support either outcome.