home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18240 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.5 KB  |  95 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Private base classes
  5. Message-ID: <1992Dec19.185132.13319@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: <921216205429_76336.3114_EHJ34-2@CompuServe.COM>
  10. Date: Sat, 19 Dec 1992 18:51:32 GMT
  11. Lines: 82
  12.  
  13. In article <921216205429_76336.3114_EHJ34-2@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
  14. >
  15. >I tried to do the following:
  16. >
  17. >class A {};
  18. >class B : private A {};
  19. >class C1 : public B, public A {};
  20. >
  21. >My compiler naturally warned me about A being both a direct and indirect
  22. >base class of C1 and so refused to compile it.  
  23.  
  24.     It was nice for your compiler to warn you.
  25.     It was wrong for it to refuse your perfectly valid request.
  26.     Your compiler is broken.
  27.  
  28.     Replicated *direct* bases are illegal, if only because there would
  29.     be no way to disambiguate them.
  30.  
  31. >My first thought, however, was that the declaration of C1 should have
  32. >been allowed.  
  33.  
  34.     Yes.
  35.  
  36. >If A is a private base class of B, no class derived from B
  37. >can access A so there should be no ambiguity in accessing members of A
  38. >from C1: the only A visible is the direct base class of C1.
  39.  
  40.     No. Both A subobjects are visible, even if only one is accessible.
  41. >
  42. >This leads to an interesting hole in the C++ programming paradigm.  A
  43. >class derived from B has no access to or knowledge of the private portion
  44. >of B (I'm ignoring friendship here).  
  45.  
  46.     'Tis a hole in your understanding, not the type system,
  47. private does not imply hidden, it has no effect on visibility.
  48. Perhaps it should though.
  49.  
  50. >Up until now, I have always believed
  51. >that, as long as the public and protected interfaces don't change, I can
  52. >do whatever I like with the implementation of B, including changing its
  53. >private interface.  
  54.  
  55.     You cant, but only because you were *wrong* before.
  56. If private meant 'hidden', then you would actually be able
  57. to do this.
  58.  
  59. >If, as I did in this case, I decide that B (and other
  60. >related classes) can be better implemented with A as a private base, I
  61. >need to know everything about classes derived from B so that I can be sure
  62. >that everything will compile.  
  63.  
  64.     This is the principal reason given by Bjarne for making
  65. private/protected/public access restrictions and not provide hiding.
  66. The argument was that changing the protection status of something
  67. should not suddenly change the semantics, instead access violations
  68. should be reported by the compiler.
  69.  
  70. >In other words, I need to have forward
  71. >knowledge of all classes that are or could be derived from B.  Similarly,
  72. >I need to know more about B than just its public and protected interfaces;
  73. >I need to know what its private base classes are before I can reliably use
  74. >it as a base class.  
  75.  
  76.     Yes, and this is why others believe private *should* mean
  77. hidden, so you dont have to know about implementation details.
  78.  
  79.  
  80. >Any thoughts?
  81.  
  82.     Your analysis is correct. My suggestion was to
  83. have a keyword 'hidden' like private that *also* provided
  84. true hiding, so the programmer could choose between the two
  85. alternatives, rather than being stuck with the one Bjarne thought
  86. best. 
  87.  
  88.     So what do you think of that?
  89.  
  90. -- 
  91. ;----------------------------------------------------------------------
  92.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  93.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  94. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  95.