home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16421 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.0 KB  |  63 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!slsvaat!us-es.sel.de!reindorf
  3. From: reindorf@us-es.sel.de (Charles Reindorf)
  4. Subject: Re: Does anyone understand this quirk?
  5. Message-ID: <1992Nov17.115630.7704@us-es.sel.de>
  6. Sender: news@us-es.sel.de
  7. Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
  8. References:  <1992Nov17.073603.5235@murdoch.acc.Virginia.EDU>
  9. Date: Tue, 17 Nov 92 11:56:30 GMT
  10. Lines: 51
  11.  
  12. In article <1992Nov17.073603.5235@murdoch.acc.Virginia.EDU>, rad2r@uvacs.cs.Virginia.EDU (Robert DeLine) writes:
  13. |> 
  14. |> For your amusement, please consider the following little program:
  15. |> 
  16. |> 
  17. |>      #include <iostream.h>
  18. |>      
  19. |>      class A
  20. |>      {
  21. |>        public:
  22. |>          A ()  { this->id(); }
  23. |>          virtual void id () const {  cout << "A\n"; } 
  24. |>      };
  25. |>      
  26. |>      
  27. |>      class B : public A
  28. |>      {
  29. |>        public:
  30. |>          B () : A() { }
  31. |>          virtual void id () const {  cout << "B\n"; }
  32. |>      };
  33. |>      
  34. |>      
  35. |>      main ()
  36. |>      {
  37. |>          B* bptr = new B();
  38. |>      }
  39. |> 
  40. |> 
  41. |> 
  42. |> The output I get from three different compilers is "A", but I was
  43. |> expecting to see "B".  Does a virtual function not become virtual till
  44. |> after the constructor is done?  What gives?  Is it my compilers or is
  45. |> this a bug in the language definition itself?  (Or is it just me? :)
  46. |> 
  47.  
  48. This is not a bug, it is one aspect of the C++ language specification, which states
  49. that the member functions (virtual or otherwise) called from within the constructor 
  50. or destructor of a class are those defined in the class or in it's base classes but
  51. *not* those defined in any derived classes, even if overridden. This is an attempt
  52. to steer clear of accesses to unconstructed (or recently destructed) parts of the
  53. derived class. The ARM section 12.7 specifies this.
  54.  
  55. |> Many thanks,
  56. |> 
  57. |> Rob DeLine
  58. |> Computer Science, University of Virginia
  59. |> deline@Virginia.EDU
  60.  
  61. All opinions here are my own etc.
  62. Charles Reindorf
  63.