home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11703 < prev    next >
Encoding:
Text File  |  1992-07-28  |  2.9 KB  |  101 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Having this=0, class-name: :main() and tasking in c++
  5. Message-ID: <1992Jul28.204329.4854@microsoft.com>
  6. Date: 28 Jul 92 20:43:29 GMT
  7. Organization: Microsoft Corporation
  8. References: <1DDA4ACFA5BF800C41@ursula.lucas.lu.se> <1992Jul27.050315.3154@sunb10.cs.uiuc.edu>
  9. Lines: 90
  10.  
  11. In article <1992Jul27.050315.3154@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
  12. >In <1DDA4ACFA5BF800C41@ursula.lucas.lu.se> KOSU_MATSB@ROUTH.KOSUFY.LU.SE writes:
  13. >
  14. >>Two (three) questions on C++:
  15. >
  16. >>Question #1:    Having a 0 "this" pointer. Standard?
  17. >
  18. >*****>    I don't know what you mean by "standard."
  19.  
  20. I think the question being asked is:
  21.  
  22. "Is it strictly legal to invoke a member function via a null pointer"
  23.  
  24. ????
  25.  
  26. IE
  27.  
  28.     Foo* pfoo = 0;
  29. ....
  30.     pfoo->doSomething();
  31.  
  32. I believe the answer is "NO it is NOT strictly legal, rather if you do this
  33. your results will be undefined."
  34.  
  35. ARM page 53 states:
  36.  
  37. "A postix expression followed by an arrow (->) followed by a 'name' is a
  38. postfix expression.  The first expression must be a pointer to a class 
  39. object and the 'name' must name a member of that class."
  40.  
  41. It is not completely clear whether "pointer to a class object" *really means*
  42. "pointer to a class object"  or rather 
  43. "expression of type 'pointer to class object' "
  44.  
  45. I take this to *really mean* "pointer to a class object"
  46.  
  47. Note, for example, if doSomething() is a virtual function, then a given
  48. implementation might either cause a runtime error if "this" is null, 
  49. or, if the implementation is "smart enough" to intuit the type of the
  50. actual object [what actual object therefore what actual type?] then possible
  51. the virtual dispatch would be optimized out.
  52.  
  53. Note also, for a data member, pfoo->member is clearly ill-defined if pfoo 
  54. is null.
  55.  
  56. Also, note that in the presence of multiple inheritence, if the null
  57. invoking ptr is to remain "null" within an invoked member function, then
  58. at dispatch time there must be a null pointer test and fixup analogous
  59. to the null pointer fixup on pointer assignment.  I don't believe compilers
  60. currently commonly do this null pointer fixup when dispatching to virtual
  61. functions -- nor would such a test and fixup on each dispatch be desirable.
  62.  
  63. Try the below example, and see if your compiler doesn't doesn't perform
  64. this null-pointer fixup on dispatch.  If it does, then you'll get all
  65. 1's output.  If any none-1's are output, then your compiler doesn't
  66. do the null pointer fixup on dispatch.
  67.  
  68. ====================================
  69.  
  70. #include <iostream.h>
  71.  
  72. class A
  73. {
  74. public:
  75.     double am;
  76.     int isNull() { return !this; }
  77. };
  78.  
  79. class B
  80. {
  81. public:
  82.     double bm;
  83.     int isNull() { return !this; }
  84. };
  85.  
  86. class C : public A, public B
  87. {
  88. public:
  89.     int isNull() { return !this; }
  90. };
  91.  
  92. main()
  93. {
  94.     C* c = 0;
  95.  
  96.     cout << c->A::isNull() << '\n';
  97.     cout << c->B::isNull() << '\n';
  98.     cout << c->C::isNull() << '\n';
  99.     return 0;
  100. }
  101.