516403ce   
   From: bouncer@dev.null   
      
   Daryle Walker wrote:   
      
   > On Friday, December 30, 2011 7:07:26 PM UTC-5, Wil Evers wrote:   
      
   >> At the point where a function's return value is constructed, its local   
   >> context is still very much alive.  Local variables and temporaries can   
   >> only be destroyed later - otherwise we would not be able to access them   
   >> from the function's return expression.  To me, this suggests that an   
   >> exception escaping from the function's return expression, or from any   
   >> of the destructors triggered when returning from the function, would   
   >> violate a promise to not throw.   
   >   
   > Here's an example of what I'm trying to say:   
   >   
   > template < typename T, int S >   
   > my_really_complex;   
   >   
   > template < typename T >   
   > my_really_complex< T, 0 >   
   > {   
      
   /* snip */   
      
   >    T  imag() const noexcept( std :: is_nothrow_default_constructible ::   
   > value )   
   >    {   
   >        // Pure-reals have no imaginary part!   
   >        return T();   
   >    }   
   > };   
   >   
   > The "imag" function has one line, and that return statement has only one   
   > part: a call to the element type's default constructor.  The noexcept   
   > attribute on the function acknowledges that.  But what about when the object   
   > is transferred from "imag" to whatever called it?   
      
   Conceptually, returning an object by value implies creating a copy of   
   the value of the return expression.  Subject to the RVO, the compiler   
   may be allowed to omit that step, but it is never required to do so.   
      
   In other words, for the "return T();" above, you should both consider   
   exceptions escaping from T's default constructor, as well as T's move   
   constructor, if it has one, or else its copy constructor.   
      
   > That transfer is handled by the C++ runtime; if it throws, do I have to add   
   > is_nothrow_move_assignable to the noexcept list of "imag" to avoid a   
   > terminate call?   
      
   The "transfer" you're referring to includes both the evaluation of the   
   return-expression and the (potentially omitted) copying of its value.   
   Both are subject to imag()'s noexcept promises.   
      
   Whether or not T is nothrow_move_assignable is irrelevant here; there is   
   no assignment in the return statement above.  It would be perfectly   
   valid for a T that has no accessible assignment operators at all.   
      
   If you really feel imag() should have a noexcept-specification: after   
   reading David Abrahams' reply to your post, I *think* the following   
   would do the job:   
      
    noexcept(is_nothrow_default_constructible::value &&   
      is_nothrow_move_constructible::value);   
      
   (I'm not 100% sure if this covers the case where T does not have an   
   accessible move constructor, but does have an accessible copy   
   constructor.  Dave?)   
      
   > Unlike an exception generated by the creation of the   
   > return's expression, there's no way for "imag" to wrap the transfer in a   
   > try-catch, since the runtime is doing it.  Note that the calling function   
   > CAN wrap the transfer.   
      
   Once the final object representing imag()'s return value has been   
   constructed, it is up to the caller to decide what to do with it.  It   
   could be copied again, assigned to some other variable, or whatever.   
   Fortunately, none of these actions can violate any noexcept promise made   
   by imag().   
      
   - Wil   
      
      
   --   
         [ 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)