From: musiphil@bawi.org   
      
   Does std::unique_ptr support self-reset? I.e. for a std::unique_ptr   
   object u, is the behavior of u.reset(u.get()) well-defined?   
      
   If I understand this correctly, it looks to me almost like the standard   
   explicitly forbids well-defined behavior:   
      
   [unique.ptr.single.modifiers]   
   >   
   > void reset(pointer p = pointer()) noexcept;   
   >   
   > Effects: assigns p to the stored pointer, then if the old value of the   
   > stored pointer, old_p, was not equal to nullptr, calls get_deleter()   
   > (old_p). [Note: The order of these operations is significant because   
   > the call to get_deleter() may destroy *this. --end note]   
   >   
   > Postconditions: get() == p. [Note: The postcondition does not hold   
   > if the call to get_deleter() destroys *this since this->get() is   
   > no longer a valid expression. --end note]   
      
   (As a side question, a call to get_deleter() "destorying *this" is   
   mentioned twice, but how could get_deleter() destroy *this, since   
   it is supposed to delete a unique_ptr::element_type object, not   
   a unique_ptr object?)   
      
   This is in contrast to std::auto_ptr, which explicitly guarantees   
   well-defined behavior for the analogous case, i.e. a.reset(a.get())   
   for a std::auto_ptr object a:   
      
   [auto.ptr.members]   
   >   
   > void reset(X* p=0) throw();   
   >   
   > Effects: If get() != p then delete get().   
   >   
   > Postconditions: *this holds the pointer p.   
      
   If the decision to forbid well-defined behavior was a deliberate one   
   (which I guess is the case), can anyone share the rationale behind it?   
      
   Thanks!   
      
   --   
   Seungbeom Kim   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)