| re: Changing access levels of inherited base members
* Dave:[color=blue]
>
> Two things need to be considered when determining an inherited base member's
> access level in the derived class: its access level in the base class and
> the type of inheritance (public, protected, or private). After this
> determination is made, the following possibilities exist for manually
> changing the access level, in the derived class, of the inherited base
> member as long as it is not inaccessible in the derived class:
>
> 1. It can be set no higher than what it was in the base
> 2. It can be set only to exactly what it was in the base
> 3. It can be set to anything
>
> If it *is* inaccessible in the derived class, it must remain so.
>
> I have seen statements in published books that 1 is the case. I have also
> seen statements in published books that 2 is the case. Empirically, I have
> observed that 3 is the case (as the results below indicate). Can somebody
> please confirm that 3 is indeed what's permitted by the language?[/color]
#3, yes, _assuming_ that by 'base member' we mean an inherited data or
function member, not the base class sub-object.
In the standard this is mostly allowed by not disallowing it, but the
discussion of 'using'-declarations refers to §11.3 on access declarations
which simply says the access can be changed, and provides some examples of
that (access declarations are deprecated and seldom if ever used since
'using'-declarations do the same thing).
However, from a design level point of view it's generally not advisable to
change access levels in derived classes.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
| 
