From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Private base classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 19 Dec 1992 18:51:32 GMT

In article <921216205429_76336.3114_EHJ34-2@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
>
>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.  

	It was nice for your compiler to warn you.
	It was wrong for it to refuse your perfectly valid request.
	Your compiler is broken.

	Replicated *direct* bases are illegal, if only because there would
	be no way to disambiguate them.

>My first thought, however, was that the declaration of C1 should have
>been allowed.  

	Yes.

>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. Both A subobjects are visible, even if only one is accessible.
>
>This leads to an interesting hole in the C++ programming paradigm.  A
>class derived from B has no access to or knowledge of the private portion
>of B (I'm ignoring friendship here).  

	'Tis a hole in your understanding, not the type system,
private does not imply hidden, it has no effect on visibility.
Perhaps it should though.

>Up until now, I have always believed
>that, as long as the public and protected interfaces don't change, I can
>do whatever I like with the implementation of B, including changing its
>private interface.  

	You cant, but only because you were *wrong* before.
If private meant 'hidden', then you would actually be able
to do this.

>If, as I did in this case, I decide that B (and other
>related classes) can be better implemented with A as a private base, I
>need to know everything about classes derived from B so that I can be sure
>that everything will compile.  

	This is the principal reason given by Bjarne for making
private/protected/public access restrictions and not provide hiding.
The argument was that changing the protection status of something
should not suddenly change the semantics, instead access violations
should be reported by the compiler.

>In other words, I need to have forward
>knowledge of all classes that are or could be derived from B.  Similarly,
>I need to know more about B than just its public and protected interfaces;
>I need to know what its private base classes are before I can reliably use
>it as a base class.  

	Yes, and this is why others believe private *should* mean
hidden, so you dont have to know about implementation details.


>Any thoughts?

	Your analysis is correct. My suggestion was to
have a keyword 'hidden' like private that *also* provided
true hiding, so the programmer could choose between the two
alternatives, rather than being stuck with the one Bjarne thought
best. 

	So what do you think of that?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------