Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!ucselx!petunia!kestrel.edu!gyro
From: gyro@kestrel.edu (Scott Layson Burson)
Newsgroups: comp.std.c++
Subject: Re: protected != public-to-derived
Message-ID: <1991Mar27.083646.17840@kestrel.edu>
Date: 27 Mar 91 08:36:46 GMT
References: <1991Mar19.165333.23908@asc.slb.com> <1991Mar24.010442.27298@kestrel.edu> <229@heurikon.heurikon.com>
Organization: Kestrel Institute, Palo Alto, CA
Lines: 62

In article <229@heurikon.heurikon.com> daves@ex.heurikon.com (Dave Scidmore) writes:
>[quote from E&S p. 255 deleted]
>
>It is hard to deny that a measure of protection has been afforded by the
>restriction that some form of the derived object be used to access protected
>base information. Any time accidents can be avoided by introducing a reasonable
>protection mechanism I fail to see why someone would oppose it. Especially since
>their is a way to bypass the protection, as stated on page 254 when talking
>about easing the restriction:
>
>    ...This would allow a class to access the base class part of an unrelated
>    class (as if it were its own) without the use of an explicit cast.
>
>So it can be seen that a cast can be used to bypass this rule.

Not in the presence of virtual base classes, which cannot be cast to a
derived class.  (I should have mentioned this before -- this is a
problem I actually encountered.)

But beyond that, in one application I found myself repeatedly
inserting such casts solely for the purpose of bypassing this rule.
(I can't defend myself if you say I must have been doing something
else wrong.  It was months ago and I don't remember all the details
about the situation.)  I will oppose even a reasonable-seeming
protection mechanism if I frequently have to bypass it with a cast,
because I believe that casts should only be used in exceptional
situations, lest people get too used to seeing them.

>							       The second
>grounds on which I feel the rule is reasonable is elequently stated just
>after the above:
>
>    ...without the use of an explicit cast. This would be the only place
>    where the language allowed this.
>
>In other words it is consistent with, and a logical extension of, existing
>protection mechanisms. If you were big on logical consistency then you might
>easily be fooled by the relaxation of this rule, expecting errors to be
>generated if you attempted to use the wrong class to change protected base
>class data. You might spend many days or even weeks hunting down such an
>obscure and subtle error in a large program.

Evidently that happened to someone, and that's why we have the rule.

See a previous posting of mine on the differences between friendship
and derivation.

>By contrast I am rarely fooled by compiler error messages. If I can not find
>anything in the program to indicate a syntactical error my first impulse is
>to grab a language reference and see if I am doing something wrong. Once I
>find the mistake I made I rarely make it again.

In general that's true for me too, but I am evidently not the only
person who had particular trouble finding this restriction given the
error messages I received from the compiler.  Perhaps if nothing else
comes of this conversation, at least compiler authors might be
persuaded to word as specifically as possible the error messages
generated on account of the restriction.  (Hello out there, are you
listening?)

-- Scott Layson Burson
Gyro@Reasoning.COM