richard@pantor.UUCP (Richard Sargent) (03/17/90)
We just got bitten by a 2.0 "gotcha". I wonder if anyone "in the know" can explain the reasons for the restriction, and whether there is some one who can provide an explanation for doing what we are trying to do. C++ 2.0 very clearly states (acc.to Lippman) that "The derived class has no special access privilege to objects of its base class. Rather, the derived class has access privilege to the nonprivate inherited members of a derived class object." (See Lippman, page 314 and 316) This either was not the case in 1.2, or the compiler was more lax in regard to this rule. The way we see the situation, we have to disagree with the restriction. However, I am not foolish enough to think that BS does not have good reasons for doing so. I sure would like to understand, 'though. To our mind, we have a class derivation tree (root class and a number of derived branches). We think that any object of a type from that tree of classes should be able to access the protected members of other objects also of that tree, but no class not in the tree. Assume we have an array of objects from that tree (or pointers to, it makes no real difference). We wish to traverse the array and access a protected member from each object (for whatever reason). It seems we should be able to use a "base*" pointer, and just access the item. So how can we accomplish this? Making the member public makes it too public :-). Any and all suggestions appreciated. Thanks. Richard Sargent Internet: richard@pantor.UUCP Systems Analyst UUCP: ...!mnetor!becker!pantor!richard
ark@alice.UUCP (Andrew Koenig) (03/18/90)
In article <56.UUL1.3#5109@pantor.UUCP>, richard@pantor.UUCP (Richard Sargent) writes: > To our mind, we have a class derivation tree (root class and a number > of derived branches). We think that any object of a type from that > tree of classes should be able to access the protected members of > other objects also of that tree, but no class not in the tree. 1.2 enforced the restriction too, and I don't think the enforcement changed significantly between 1.2 and 2.0. One of the main reasons for the restriction is that otherwise there's very little practical difference between `protected' and `public.' For example: class Foo { protected: int i; }; Now, suppose I want to clobber member `i' of a `foo' object. I would like to write this: void clobber(Foo& f, int n) { f.i = n; } but I can't quite do that directly. What if I do this, though? class dummy: public Foo { friend void clobber(Foo&, int); }; Now `dummy' can get at any protected member of Foo, and so can its friends. By making `clobber' a friend, I open Foo up to it, and completely without permission from the author of Foo. -- --Andrew Koenig ark@europa.att.com
jkuhn@walt.cc.utexas.edu (Jeff Kuhn) (03/20/90)
In article <56.UUL1.3#5109@pantor.UUCP> richard@pantor.UUCP (Richard Sargent) writes: >We just got bitten by a 2.0 "gotcha". I wonder if anyone "in the know" >can explain the reasons for the restriction, and whether there is >some one who can provide an explanation for doing what we are trying >to do. > >C++ 2.0 very clearly states (acc.to Lippman) that "The derived class >has no special access privilege to objects of its base class. Rather, >the derived class has access privilege to the nonprivate inherited >members of a derived class object." (See Lippman, page 314 and 316) > >This either was not the case in 1.2, or the compiler was more lax >in regard to this rule. The Zortech 2.0 version doesn't seem to catch the error, but the Intek 2.0 compiler and (I believe) the AT&T compiler's won't let you access base member of another object from within a derived class. >The way we see the situation, we have to disagree with the restriction. >However, I am not foolish enough to think that BS does not have good >reasons for doing so. I sure would like to understand, 'though. I disagree too. >To our mind, we have a class derivation tree (root class and a number >of derived branches). We think that any object of a type from that >tree of classes should be able to access the protected members of >other objects also of that tree, but no class not in the tree. > >Assume we have an array of objects from that tree (or pointers to, >it makes no real difference). We wish to traverse the array and >access a protected member from each object (for whatever reason). >It seems we should be able to use a "base*" pointer, and just >access the item. So how can we accomplish this? > >Making the member public makes it too public :-). The only way that I have found to get around this is to typecast your base class pointer to a pointer to the derived class you want access through. This is not the safest solution. example: derived::f() { base *pb; ((derived *)pb)->member; } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jeff R. Kuhn jkuhn@ccwf.cc.utexas.edu Nth Graphics Austin, Texas
williams_j@apollo.HP.COM (Jim Williams) (03/22/90)
Andrew Koenig writes (6443): > For example: > > class Foo { > protected: > int i; > }; > > Now, suppose I want to clobber member `i' of a `foo' object. I would > like to write this: > > void clobber(Foo& f, int n) { f.i = n; } > > but I can't quite do that directly. What if I do this, though? > > class dummy: public Foo { friend void clobber(Foo&, int); }; > > Now `dummy' can get at any protected member of Foo, and so can its > friends. By making `clobber' a friend, I open Foo up to it, and > completely without permission from the author of Foo. Couldn't you also write: class FooPub { public: int i; }; void clobber (Foo& f, int n) { ((FooPub*)&f)->i = n; } Why have private/protected members at all? :-)
chip@tct.uucp (Chip Salzenberg) (03/23/90)
According to ark@alice.UUCP (Andrew Koenig): > class Foo { > protected: > int i; > }; > > class dummy: public Foo { friend void clobber(Foo&, int); }; > >Now `dummy' can get at any protected member of Foo, and so can its >friends. By making `clobber' a friend, I open Foo up to it, and >completely without permission from the author of Foo. I wouldn't say "completely without permission." The author of Foo did, after all, mark "i" as "protected" instead of "private." -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."