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."