home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / cplus / 1099 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  4.4 KB
  1. Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!darwin.sura.net!mips!swrinde!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc10.cs.uiuc.edu!pjl
  2. From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: this == 0 for nonvirtual functions
  5. Keywords: this virtual function undefined
  6. Message-ID: <1992Aug21.044448.8282@sunb10.cs.uiuc.edu>
  7. Date: 21 Aug 92 04:44:48 GMT
  8. References: <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> <1992Aug20.215455.17279@microsoft.com>
  9. Sender: news@sunb10.cs.uiuc.edu
  10. Distribution: usa
  11. Organization: University of Illinois at Urbana-Champaign
  12. Lines: 78
  13.  
  14. In <1992Aug20.215455.17279@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  15.  
  16. >In article <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
  17. >|    To reiterate, all I would like is to guarantee that the *call*
  18. >|    to a non-virtual member-function will succeed and that it's my
  19. >|    responsibility to check for a non-nil 'this'.
  20.  
  21. >First, note that this would not come at "zero" cost.  As in the case of
  22. >assigning to a reference, requiring "this" to be non-null allows compilers
  23. >to avoid generating code to preserve nullness when adjusting pointers
  24. >in the case of MI.  In the case of references, this issue has already
  25. >been reviewed and decided upon: one is not allowed to have null references.
  26.  
  27.     I was under the impression that for MI, once a this pointer became
  28.     zero it has to stay zero, so it constitutes a special-case now.
  29.     Hence, why wouldn't be a zero-cost feature?
  30.  
  31. >Further, note that member functions can be called either on a pointer or
  32. >on a reference.  If the language were to PERMIT calling member functions
  33. >on a null pointer, such would not ALLOW *you* to test for null "this" inside
  34. >you member functions, but rather would REQUIRE all of *us* to test for
  35. >null "this" inside ALL *our* non-virtual member functions -- because a user
  36. >of our class such as yourself could then legally call *our* member functions via
  37. >a null pointer.  If such were the case then, the only sane remedy C++
  38. >programmers would have would be to declare all their member functions virtual.
  39. >Then *you* *still* could not legally call these members on a null pointer --
  40. >but many member functions would now be needlessly slow and generate needlessly
  41. >large code.
  42.  
  43.     I don't think that it would require everyone to test this for
  44.     zero.  I had said that this would be usedful only if a majority
  45.     of member-function calls were made via a pointer, i.e.,
  46.     linked-list and perhaps other container classes that use linked
  47.     lists for their implementation.
  48.  
  49.     Such a class would have as part of it's documentation: "This
  50.     class is null-this safe" meaning it would do something sensible,
  51.     or more likely nothing at all, for a null this pointer.  
  52.  
  53.     Other "concrete object" type classes, i.e., complex numbers,
  54.     would have no need of being "null-this safe."
  55.  
  56.     It wasn't my intent to introduce the feature just so all
  57.     programmers could forbid it by making everything virtual.
  58.  
  59.     If programmers elected not to check the this pointer, then the
  60.     program, if a member is accessed via a null-this, would most
  61.     likely crash or at least be undefined; this is _exactly_ the
  62.     way language is defined now; hence, for programmers who ignore
  63.     it, the (errant) behavior of their programs is unchanged.
  64.  
  65.     *****************************************************************
  66.     Hence, adding my proposal changes nothing for those who ignore
  67.     it.
  68.     *****************************************************************
  69.  
  70.     Again, all I want is the *call* to succeed; after that, I'm on
  71.     my own.
  72.  
  73. >I suggess instead that you use friend functions or static member functions 
  74. >where you feel you must address null pointers implicitly.  Alternately, note
  75. >that the users of your class may be the ones in the best position to perform
  76. >the null pointer tests [explicitly].
  77.  
  78.     Perhaps [with regard to users checking null tests]; but I think
  79.     that one of the _themes_ of programming in C++ is to eliminate
  80.     tedium and errors introduced thereby: virtual functions
  81.     eliminate switch statements missing a case; exception-handling
  82.     will eliminate having to check the return value from new to see
  83.     if it failed, etc.
  84.  
  85.     I see my (modest) proposal in the same light.
  86.  
  87.     Further comments?
  88. -- 
  89.     - Paul J. Lucas                University of Illinois    
  90.       AT&T Bell Laboratories        at Urbana-Champaign
  91.       Naperville, IL            pjl@cs.uiuc.edu
  92.