0e14d780   
   From: bouncer@dev.null   
      
   Michael Kilburn wrote:   
      
   > On Jun 9, 1:11 pm, Wil Evers  wrote:   
   >   
   >> In short, I think the impact of adding a destructor overload to the   
   >> language should not be underestimated.  It might well be   
   >> comparable, both in terms of complicating the language even   
   >> further, and in terms of implementation effort, to the introduction   
   >> of move semantics in C++11.   
   >   
   > I doubt it... Next to new ultra-complicated move-and-init semantic   
   > of C ++11 this feature is a simpleton -- small, plain and   
   > well-contained.   
      
   Well, destructors resemble copy constructors/assignment operators   
   because they (1) are (often) implictly called by the compiler and   
   (2) may be implicitly generated by the compiler. Just as the move   
   constructor/assignment operator adds an additional overload for the   
   compiler to call and/or generate, so does the destructor overload   
   you suggested.   
      
   It would require a set of rules specifying how the overloads are   
   recognized by the compiler, which of these is selected when, the   
   semantics that the compiler will assume apply to each of them, the   
   conditions under which they are implicitly generated, and the   
   signatures the compiler will emit when they are.  That is about the   
   same set of questions the designers of C++11's move semantics had to   
   answer.  Finally, once all of this is specified and added to the   
   standard, the community will have to be educated about it.   
      
   >> To justify that, the benefits must be sufficiently clear.  In this   
   >> case, I don't think they are, especially because we would still be   
   >> expected to deal with the case where the destructor should not   
   >> throw, and because workarounds exist.   
   >   
   > There is no workaround -- there is no way to determine if given dtor   
   > is called by stack unwinding or not.   
      
   The obvious workaround is to put logic that may need to report an   
   exception in an explicitly called member function instead of in the   
   destructor.  I know that's not a perfect solution, which is why I   
   called it a workaround.  However, it is easy to understand and   
   implement, and not really that hard to use.   
      
   Regards,   
      
   - 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)