home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20094 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.3 KB  |  85 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Is this C++ advice from an OO book true?  (beginner question)
  5. Message-ID: <1993Jan27.170823.770@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <sherman.727849469@foster>
  10. Date: Wed, 27 Jan 1993 17:08:23 GMT
  11. Lines: 72
  12.  
  13. In article <sherman.727849469@foster> sherman@unx.sas.com (Chris Sherman) writes:
  14. >I read the following from a book that adviced how to do software projects
  15. >using OO-type languages.  In one of the appendixes, it gave some advice
  16. >on how to write C++ programs.  
  17. >
  18. >I don't understand one of the book's recommendations:
  19. >
  20. >  11.  Call virtual class constructors in dervied class constructors.
  21.  
  22.     Yes, you have to do this ...
  23. >
  24. >     I pity the poor fools who have to spend nights and weekends searching
  25. >     for the reason that a class variable occasionally takes on strange,
  26. >     unexpected values .  .  .  only to find through their bleary eyes
  27. >     that they forgot to allocate space for a virtual base (super) class,
  28. >     so that storage is allocated for the base class's members.  Even if
  29. >     the class has no members, declare it--you never know what future
  30. >     changes will come back to haunt you (or the person who inherits your
  31. >     mine field)!
  32.  
  33.     I dont understand this gibberish either.
  34. >
  35. >Now, I thought that a contructor will allocate everything it needs, even
  36. >if it inherits from other classes.  
  37.  
  38.     The system -- not the constructor -- allocates storage.
  39. The constuctor is merely responsible for initialising it.
  40.  
  41. >I never heard that you had to call
  42. >all the constructors in all the bases classes manually.  
  43.  
  44.     You dont. Only if you have virtual bases requiring
  45. non-default initialisation.
  46.  
  47. >This kind of
  48. >blows the idea that a class shouldn't have to explicitly know who its
  49. >parents are, right?
  50.  
  51.     You mean 'grand-parents'. Yes, it blows that idea,
  52. and it is not good. But for virtual bases requiring non-default
  53. initialisation only.
  54. >
  55. >Or if this is very good advice, could someone give an example showing why
  56. >it is true?
  57.  
  58.     Virtual bases can have more than one child.
  59. Which one is responsible for supporting the virtual base in its old age? 
  60.  
  61.     Answer: none of them, the the very youngest descendant only: 
  62. the most derived class.
  63.  
  64.     Why? Well, what is a better way to decide?
  65. The initialising class must be uniquely determined somehow.
  66.  
  67. >
  68. >This is a beginner question obviously--thanx for any help!
  69.  
  70.     Its NOT a beginner question. You are perfectly correct
  71. in observing that for virtual bases that non-default initialisation
  72. by the most derived class has the unfortunate consequence
  73. that you have to know all the virtual bases in the subobject
  74. DAG that require non-default initialisation, and then
  75. initialise them.
  76.  
  77.     This is not good (the grandparents of a class should
  78. be anonymous). But it seems hard to find a better way.
  79.  
  80. -- 
  81. ;----------------------------------------------------------------------
  82.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  83.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  84. ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
  85.