home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / std / cplus / 1115 < prev    next >
Encoding:
Text File  |  1992-08-25  |  3.1 KB  |  62 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: this == 0 for nonvirtual functions
  5. Message-ID: <1992Aug25.192245.10965@microsoft.com>
  6. Date: 25 Aug 92 19:22:45 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> <1992Aug20.215455.17279@microsoft.com> <1992Aug21.044448.8282@sunb10.cs.uiuc.edu>
  9. Distribution: usa
  10. Keywords: this virtual function undefined
  11. Lines: 49
  12.  
  13. In article <1992Aug21.044448.8282@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
  14. |    If programmers elected not to check the this pointer, then the
  15. |    program, if a member is accessed via a null-this, would most
  16. |    likely crash or at least be undefined; this is _exactly_ the
  17. |    way language is defined now; hence, for programmers who ignore
  18. |    it, the (errant) behavior of their programs is unchanged.
  19. |
  20. |    *****************************************************************
  21. |    Hence, adding my proposal changes nothing for those who ignore
  22. |    it.
  23. |    *****************************************************************
  24. |
  25. |    Again, all I want is the *call* to succeed; after that, I'm on
  26. |    my own.
  27.  
  28. The call already doesn't necessarily succeed in the virtual case.
  29. The call already doesn't necessarily succeed in the null-this-from-a-ref case.
  30. You are asking for support for a special case where a non-virtual member
  31. function is invoked via a null pointer.  Asking for this singular special
  32. case seems awfully non-orthogonal to me.  If you were to insist on this,
  33. then it should work for null-refs and for virtual functions....
  34.  
  35. |    Perhaps [with regard to users checking null tests]; but I think
  36. |    that one of the _themes_ of programming in C++ is to eliminate
  37. |    tedium and errors introduced thereby: virtual functions
  38. |    eliminate switch statements missing a case; exception-handling
  39. |    will eliminate having to check the return value from new to see
  40. |    if it failed, etc.
  41. |
  42. |    I see my (modest) proposal in the same light.
  43.  
  44. In the early days of Objective-C method invocation on a null pointer was
  45. defined to be a no-op.  The result was intended to save programmers from
  46. having to handle special cases.  In practice the result was that it took
  47. about a week to track down each case where some method was invoked on
  48. a null pointer -- because the result of such a mistake was a null pointer
  49. -- resulting in another no-op method call, resulting in a null pointer --
  50. resulting in another no-op call.  Fortunately, we had access to source and
  51. quickly patched the method dispatch routine so that invoking a method via
  52. a null pointer resulted instead in an assert.  Then bugs were caught quickly.
  53.  
  54. Therefore I suggest rather than allowing method invocation on null pointers
  55. what one really needs is a good way to always assert on such "mistakes."
  56. Allowing overloadable operator dot is one step in this direction.  Further,
  57. defining null ptr invocations as being illegal *allows* quality compiler
  58. implementations the option of inserting runtime checks on such illegalities
  59. during debug mode.  Better yet would be if C++ supported better ways to specify
  60. class invarients checking on method dispatch and return.
  61.  
  62.