From: daniel.kruegler@googlemail.com   
      
   Am 12.08.2013 19:48, schrieb Greg Marr:   
   > On Monday, August 12, 2013 10:23:38 AM UTC-4, SG wrote:   
   >> Actually, this looks good to me. It does not support self-reset but it   
   >> does not have to according to the standard. What do you think is   
   >> non-conforming about it?   
   >   
   > It does support self-reset, exactly as does the MSVC implementation   
   > that Daniel Krugler said is non-conforming, because it doesn't   
   > call get_deleter()(old_value) if the old value and the new value   
   > are the same.   
      
   I'm confused by your statement here: *If* the argument of reset() is the   
   owned pointer itself, the effects will be a double-delete: The first one   
   within reset and the second one in the first of another reset or the   
   destructor of std::unique_ptr.   
      
   > This is different than the reset() later in the same file, which is   
   >   
   >         void   
   >         reset(pointer __p = pointer()) noexcept   
   >         {   
   >           using std::swap;   
   >           swap(std::get<0>(_M_t), __p);   
   >           if (__p != nullptr)   
   >             get_deleter()(__p);   
   >         }   
      
   I'm confused a second time: Sebastian Gesemann was referring to exactly   
   this version of reset as I understand his response.   
      
   > The difference is   
   >           if (__p != nullptr)   
   > vs   
   >           if (__p != pointer())   
      
   This is not a semantics difference, because as of the NullablePointer   
   requirements imposed on type 'pointer' we can build the following logic   
   chain:   
      
   a) __p is a value of (possibly const) 'pointer' and nullptr is a   
   (possibly const) value of type std::nullptr_t, according to Table 25 —   
   NullablePointer requirements [nullablepointer]   
      
   __p != nullptr   
      
   has the semantics of   
      
   !(__p == nullptr)   
      
   and the sub-expression   
      
   __p == nullptr   
      
   has the semantics of   
      
   __p == pointer()   
      
   b) Using the same starting point we note that   
      
   __p != pointer()   
      
   has the semantics of   
      
   !(__p == pointer())   
      
   and we end up with the same essential effects as in (a).   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ 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)