119742a6   
   From: bouncer@dev.null   
      
   Joshua Maurice wrote:   
      
   > On Mar 2, 2:38 am, Wil Evers  wrote:   
      
   >> Kris Prad wrote:   
      
   >> > My question:   
   >> > Eventually ~auto_ptr() must see the underlying class definition for   
   >> > the code to work correctly. So, why is this only a warning, and not a   
   >> > full fledged error?   
   >>   
   >> Because at some point, someone decided that it was a good idea to allow   
   >> for this kind of nonsense, probably to keep the C folks happy.   
   >> Be thankful to the EDG guys for spotting this... and remember there is   
   >> only one warning level: warnings are errors.   
   >   
   > I've always wondered this myself. As far as I can tell, "delete p;",   
   > where p is a pointer to an incomplete type, is bad style. At least bad   
   > style. I don't want to try to peruse the standardeze on the subject,   
   > and I don't know offhand whether it's always undefined behavior, or   
   > whether it's undefined behavior merely for non-POD types and/or type   
   > with non-trivial destructors.   
      
   According to the standard, the behaviour is undefined if p is a pointer   
   to an incomplete type that has a non-trivial destructor or a   
   deallocation function.   
      
   In other words: the programmer must check that this is not the case,   
   because the compiler can't.  But if the programmer checked the relevant   
   header file, then why couldn't it simply be #included?  "Bad style" is   
   really too kind.   
      
   Things are even worse if, as in the auto_ptr example above, the type   
   pointed to is a template parameter, in which case it is up to the user   
   of the template to ensure the compiler knows how to delete a T.  Some   
   harmless statement that requires T to be fully defined (such as a   
   "(void) sizeof(*p);" just above the delete-expression) can be very   
   helpful in such situations.   
      
   > In practice, it seems most compilers are   
   > happy to accept this, and will just free the memory without calling   
   > any destructor.   
   >   
   > This is also very related to "delete p;" where p is a pointer to   
   > void.   
   >   
   > Why not make such things "required diagnostics" in the standard, ergo   
   > hopefully resulting in proper "failure to compile" error messages from   
   > compilers? I guess I'm asking how does the current state of affairs   
   > make "the C people" happy? If they want to free memory with free(),   
   > they're free to do so, but the new delete thingy could have been made   
   > to take only pointers to complete (and non-void) types.   
      
   I was thinking about a mixed C/C++ environment in which some objects   
   of a particular type without a destructor are allocated with   
   malloc(), others with a new-expression, and the global   
   ::operator delete(void *) simply forwards to free().  If that's the   
   case, it won't be necessary to keep track of the way a specific instance   
   was allocated: delete and free() will do the same thing.   
      
   I'm pretty sure compiler vendors are reluctant to break exisiting code   
   by changing something their users could get away with into a hard   
   compile-time error.  But I'm on your side: in the long run, we   
   all pay a high price for that kind of tolerance.   
      
   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)