home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18114 < prev    next >
Encoding:
Text File  |  1992-12-17  |  2.7 KB  |  66 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Virtual base classes
  5. Message-ID: <9235216.12447@mulga.cs.mu.OZ.AU>
  6. Keywords: virtual, class
  7. Sender: news@cs.mu.OZ.AU
  8. Organization: Computer Science, University of Melbourne, Australia
  9. References: <1992Dec2.163139.8326@camax.com> <1992Dec3.202705.16646@ucc.su.OZ.AU> <rmartin.723768537@thor>
  10. Date: Thu, 17 Dec 1992 05:47:47 GMT
  11. Lines: 53
  12.  
  13. rmartin@thor.Rational.COM (Bob Martin) writes:
  14.  
  15. >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  16. >
  17. >|    As a rule of thumb, all public inheritance should be made virtual,
  18. >|    private inheritance non-virtual. (See papers by Markku Sakkinen
  19. >|    for a full explanation of why)
  20. >
  21. >I am in some disagreement with the above statement.  Virtual
  22. >inheritance is a necessary evil IMHO.  It hobbles the language in
  23. >several important ways.  It prevents valid downcasting.  (No flames
  24. >please.  I know downcasting is suboptimal, but prior to covariant return
  25. >types it is sometimes necessary).  Also, VI adds some minor
  26. >inefficiencies to virtual dispatch.  The worst aspect of VI, and the
  27. >one which I suspect makes you want to declare all public inheritance
  28. >as virtual, is that it must be used long before you know you need it.
  29. >i.e. In the diagram above, it is B and C which must virtually inherit
  30. >from A, but it is not until you have recognized the need for F that
  31. >you know that virtual inheritance is needed.  
  32. >
  33. >This is really quite sick.  Proper design of a project can alleviate
  34. >this a bit since the design will alert you to the need before you have
  35. >written any of the classes.  But the problem can still occur later if
  36. >you extend the project by creating new classes.
  37. >
  38. >[...] I don't think it is acceptable to proliferate the
  39. >disadvantages of virtual inheritance by making all public inheritance
  40. >virtual.
  41.  
  42. You have listed three disadvantages.
  43.  
  44.      1. VI prevents downcasting.
  45.  
  46.     Well, unless you're willing to brave the flames, we can't really
  47.     discuss this one much ;-) Suffice it to say that I for one don't
  48.     consider this a disadvantage.
  49.  
  50.      2. VI must used long before you know you need it.
  51.  
  52.     On the contrary, it is NON-virtual inheritance that causes this
  53.     problem. If you use the "all public inheritance should be virtual"
  54.     rule, then this problem does not occur.
  55.  
  56.      3. VI is less efficient.
  57.     True. But I wouldn't say that this "hobbles the language".
  58.     The efficiency cost is necessary if classes are to be truly
  59.     open.
  60.  
  61. -- 
  62. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  63. This .signature virus is a self-referential statement that is true - but 
  64. you will only be able to consistently believe it if you copy it to your own
  65. .signature file!
  66.