home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!umn.edu!csus.edu!borland.com!pete
- From: pete@borland.com (Pete Becker)
- Newsgroups: comp.lang.c++
- Subject: Re: Private base classes
- Message-ID: <1992Dec17.171343.26787@borland.com>
- Date: 17 Dec 92 17:13:43 GMT
- References: <921216205429_76336.3114_EHJ34-2@CompuServe.COM>
- Sender: news@borland.com (News Admin)
- Organization: Borland International
- Lines: 29
- Originator: pete@genghis.borland.com
-
- In article <921216205429_76336.3114_EHJ34-2@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
- >In the excitement generated by the fact that someone had managed to post
- >to comp.lang.c++ from CompuServe, the intent of my original posting was
- >lost. Here it is again:
- >
- >I tried to do the following:
- >
- >class A {};
- >class B : private A {};
- >class C1 : public B, public A {};
- >
- >My compiler naturally warned me about A being both a direct and indirect
- >base class of C1 and so refused to compile it. I was able to get around
- >the problem:
- >
- >class CA : public A {};
- >class C2 : public B, public CA {};
- >
- >My first thought, however, was that the declaration of C1 should have
- >been allowed. If A is a private base class of B, no class derived from B
- >can access A so there should be no ambiguity in accessing members of A
- >from C1: the only A visible is the direct base class of C1.
-
- No. The only A _accessible_ from C1 is the direct base. Both A's
- are visible. The rule is that ambiguities are detected before applying
- access restrictions. That's so that changing an access specifier won't
- result in ambiguities.
-
- -- Pete
-