Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.std.c++
Subject: Re: protected != public-to-derived
Message-ID: <229@heurikon.heurikon.com>
Date: 24 Mar 91 07:02:58 GMT
References: <1991Mar19.165333.23908@asc.slb.com> <1991Mar24.010442.27298@kestrel.edu>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 80

In article <1991Mar24.010442.27298@kestrel.edu> gyro@kestrel.edu (Scott Layson) writes:

>The second sentence of section 11.5 of E&S (p. 253) reads:
>
>   A friend or a a member function of a derived class can access a
>   protected nonstatic member of one of its base classes only through
>   a pointer to, reference to, or obejct of the derived class (or any
>   class derived from that class).
>
>I have bumped my head on this rule a couple of times, and frankly
>don't agree with the rationale given in E&S for its existence (see the
>commentary starting on the bottom of p.254).  The last sentence of
>that rationale, which describes a bug someone once had which the rule
>would have prevented, reads:
>
>   Naturally, the use of a virtual function for performing the update
>   would have avoided the problem.
>
>Seems to me that this sentence admits that the bug really had quite
>another cause than the mistaken access of a protected member.

I think you may be missing the point. The text which you neglected to
include stated:

    There are examples where the restriction appears to provide protection
    against accidents. For example suppose I am running a bank, and have
    many different kinds of accounts. I would like to have a base class
    "Account", that has information common to all kinds of accounts,
    including including the account balance, so a friend of "Account" can
    walk the list of all "Accounts" and tell me the financial position of
    my bank at any time. Each kind of "Account", however, has its own rules
    for updating the balance (for example, what rate of interest is paid,
    when it is compounded, what types of deposits are accepted, special
    penalties for early withdrawal, and so on), so the derived classes which
    are all the different kinds of accounts contain code for updating the
    balance. The member functions of "checking_accounts", however should
    not be able to access the balance in an "AutoLoan_account." The
    restriction prevents that.

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

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. Ultimately, the whole process
may only take a few minutes to a few hours to eliminate the compilation
error. If, like the bug created by the relaxed rules, it takes days or weeks
for you to eliminate a compilation error that results form a less than full
understanding of the language, then you might consider a different line of
work. At the very least you would have trouble explaining it to your boss.

In other words I would rather spend a few minutes looking through E&S than
a few days hunting down an obscure bug. In that sense I think the protection
is worth the cost, especialy when I can bypass it and at the same time make
it quite clear that I intended to by using a cast.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com