03792c77   
   From: moreno_news@mailinator.com   
      
   On 11-11-11 08:28 AM, Gil wrote:   
      
   > with regard to the OP's UB question the argument in 5.2.2 is even   
   > weaker   
   > than simply using 9.3.1/2 [class.mfct.non-static]:   
   > "If a non-static member function of a class X is called for an object   
   > that is not of type X, or of a type derived from X, the behavior is   
   > undefined."   
      
   Hmmm, I'm not too sure that this would be a convincing argument,   
   in that someone insisting on using the trick of this == NULL could   
   still insist that the *static type* of the pointer is the right   
   type, so you're "formally" calling the member function for an   
   object of the correct type.   
      
   IOW, I think 9.3.1/2 is more contextual than the previous one   
   posted by Daniel, since this one puts the emphasis on *the type*   
   of the object.   
      
   > however, imo both 5.2.2 and 9.3.1/2 do not handle the invalidity of   
   > 'empty object'.   
      
   Empty object???   What does a NULL pointer have to do with *empty*   
   object??   The situation here is *no object*, which is what a NULL   
   pointer describes.   
      
   > so we definitely have a defect that should be addressed with a wording   
   > change   
   > in 9.3.1/2:   
   >   
   > "...or if the object is an empty object, the behavior is undefined."   
      
   I don't think the standard would ever use the wording "empty object",   
   since there is no such thing.  (someone correct me if I'm wrong)   
      
      
   Carlos   
   --   
      
         [ 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)