[comp.lang.c++] Visibility Bug in 1.2?

vilot@csdpie.dec.com (Michael J. Vilot) (01/07/89)

On p. 196 of "The C++ Programming Language," Bjarne describes the semantics
of class member visibility for derived classes, and says:
 
    "It is also possible to declare some, but not all, of the public members
     of a base class public members of a derived class."
 
He goes on to demonstrate it in an extension to an example.
In the example, he never actually shows an example of code
accessing it ... here's a fragment that fails:

	class Base {
	  int z;
	public:
	  int d, e;
	};

	class Derived : Base {	// Base's members are now private in Derived
	  int a, b, c;	        // also private
	public:
	  Base::d;		// should make Base::d public
	};

	main()
	{
	  Derived y; 
	  y.d =1;    // error reported here
	}

Here's the transcript:
	designer C++ Programming System, release 1.2 Vms4.5.1
	Copyright 1987, Glockenspiel Ltd., Dublin, Ireland
	Glockenspiel System V.3 compatible C pre-processor, release.4
	AT&T C++ Translator, release 1.2 Vms4.5.1
	Copyright 1984 AT&T, Inc. and 1987 Glockenspiel Ltd.
	"test.cxx;0", line 17: error:  d is from private base class
	Error executing command CFXX +L +l +ftest.CXX;0 <test.IXX;0
	C++ Driver terminating. 

Has this been reported before? Is it fixed yet?  Is it also in g++?

==
Mike Vilot			Self-employed.  Consulting at:
e-mail:	       			vilot%ontologic@erl.mit.edu
or:				vilot%keeper.dec@decwrl.dec.com
when that fails:    		(508)467-6166 [for now]

dcb@siesoft (dcb) (01/11/89)

Hello there,

	I am searching for the address & phone number 
of a small computer company called
ParcPlace (sp?) based in California, USA. I believe it is a spin-off
from Xerox. They sell products in the C++/Smalltalk/Hypertext area
that we would like to buy.

Thanks,

David C Binderman

Siemens SDG
65-73 Crockhamwell Road
Woodley
Reading
Berkshire
UK
RG5 3JP
e-mail: dcb@siesoft.uucp
		...!ukc!siesoft!dcb

vilot@erl.mit.edu (Michael J. Vilot) (01/13/89)

Summary:  It's not a bug!

I did a little more research on the example.  In particular, I re-read pp.
196-197 more carefully:

	"It is also possible to declare some, but not all, of the
	public members of a base class public members of a derived class.
	^^^^^^                         ^^^^^^
	...
	    [on p. 192, employee::name & employee::department are _public_]
	...
	Naturally, it is -> NOT <- possible to make a 
	private member of a base class a public member of a derived class.
	^^^^^^^                          ^^^^^^
	It is not possible to make overloaded names public using this
	notation." 

In his 1987 Usenix paper "The Evolution of C++: 1985 to 1987", Bjarne
clears up some issues and adds some features to the language.  Among the
clarifications is a mention of this visibility issue (p. 4):
	"It was always possible to specify that a member of
	a private base should be considered public:
	...
		[another example where the base members are _public_]
	...

	"The complementary operation, making a member of
	public base private, is also allowed...
<< I tried this, it didn't seem supported ... >>
	Note that [doing this] implies that [the base class] is no longer a
	sub-type of [the derived class]: that is, there is no implicit
	coercion of a pointer to [the derived class] to a pointer to [the
	base class] and public members of [the base class] are not
	automatically public members of [the derived class]."

I have also encountered a related issue:  a friend of a derived class is
_not_ automatically a friend of the base class -- if you really want this,
you have to explicitly declare the function/class a friend of each.
* BUT * (p. 195 of the book):
	"An alternative, and sometimes cleaner, solution is for the derived
	class to use only the public members of its base class."