home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / cplus / 1089 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.6 KB  |  75 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!wupost!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc10.cs.uiuc.edu!pjl
  3. From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
  4. Subject: this == 0 for nonvirtual functions
  5. Message-ID: <1992Aug18.045605.14220@sunb10.cs.uiuc.edu>
  6. Keywords: this virtual function undefined
  7. Sender: news@sunb10.cs.uiuc.edu
  8. Organization: University of Illinois at Urbana-Champaign
  9. Date: Tue, 18 Aug 1992 04:56:05 GMT
  10. Lines: 63
  11.  
  12.     The ARM, p. 176 says:
  13.  
  14.         The effect of calling nonstatic member function of a
  15.         class C for something that is not an object of class C
  16.         is undefined.
  17.  
  18.         For example,
  19.  
  20.             ((X*)0)->f();
  21.         
  22.         is not guaratneed to work. ... Even for non-virtual
  23.         functions, one should expect this trick to fail
  24.         eventually because specialized C++ implementations might
  25.         assume something about the contents of objects even when
  26.         calling nonvirtual functions.  In particular, on might
  27.         expect implementaions instrumented for debugging,
  28.         interpretersm and implementations supporting dynamic
  29.         loading to be sensitive to "housekeeping" information
  30.         placed in the objects by the compiler.
  31.  
  32.         Natually, this trick would work only f() either checks
  33.         its 'this' pointer before accessing any members or...
  34.     
  35.     IMHO, the ability to *depend upon* the (desired) fact that
  36.     *calling* a non-virtual member-function with a nil pointer is
  37.     *guaranteed* to be harmless seems worthwhile (and its addition
  38.     to the language wouldn't break anything as far as I can tell).
  39.  
  40.     The alleged existence of "specialized C++ implementations" seems
  41.     rather a "fringe" reason for saying that it's undefined; the
  42.     standard could *make* it defined.
  43.  
  44.     The last paragraph is also vague; does it really mean "...this
  45.     trick is *guaranteed* to work only if f() either checks its
  46.     'this' pointer before accessing any members...?"
  47.  
  48.     The simple example where this is handly is a linked-list class
  49.     where the objects are always dealt with via pointer.  The class,
  50.     in its quest for robustness, could easily check its 'this'
  51.     pointer before doing anything; consider also:
  52.  
  53.         void Link::DeleteAll() {
  54.             for ( Link *p = this, *q; p; p = q ) {
  55.                 q = p->next;
  56.                 delete p;
  57.             }
  58.         }
  59.     
  60.     There's an initial test on 'this' so if I call DeleteAll() with
  61.     a nil pointer, it should do nothing.  It would be nice to not
  62.     have to check for nil in such cases; requiring it is prone to
  63.     user error.
  64.  
  65.     To reiterate, all I would like is to guarantee that the *call*
  66.     to a non-virtual member-function will succeed and that it's my
  67.     responsibility to check for a non-nil 'this'.
  68.  
  69.     Comments?
  70.  
  71. -- 
  72.     - Paul J. Lucas                University of Illinois    
  73.       AT&T Bell Laboratories        at Urbana-Champaign
  74.       Naperville, IL            pjl@cs.uiuc.edu
  75.