Consider the following class heirarchy:

class Base {
 public:
  void SomeMethod(void) { }
};

class Derived : public Base {
 public:
  void AnotherMethod(void) { }
};

class Ultimate : private Derived {
 public:
  Derived::AnotherMethod;  // Ok; changes access by using the name
  Derived::SomeMethod;     // Is this OK or an error?
  Base::SomeMethod;        // Error; Base is not an immediate base of Ultimate.
};

Can somebody point me to a definitive place in the ARM that explains
whether the attempt to change the access of Derived::SomeMethod in
class Ultimate is either Okay, an Error, or Implementation Defined?

If there is no definitive place in the ARM, has the ANSI C++ committee
yet made a decision on this matter?

(Note: the best I have found so far is ARM 11.3, which says that

"The access to a member of a base class in a derived class can be adjusted
by mentioning its qualified-name in the public or protected part of a
derived class declaration."

This seems ambiguous in this situation. All ther examples in 11.3 only
use immediate base classes.)

Thanks,
Kevin Coombes <krc@math.umd.edu>

In article <1992Jun26.194754.10694@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>
>If there is no definitive place in the ARM, has the ANSI C++ committee
>yet made a decision on this matter?
>
>(Note: the best I have found so far is ARM 11.3, which says that
>
>"The access to a member of a base class in a derived class can be adjusted
>by mentioning its qualified-name in the public or protected part of a
>derived class declaration."
>
>This seems ambiguous in this situation. All ther examples in 11.3 only
>use immediate base classes.)

 I would recommend that the words "base class" standing
on their own be removed everywhere the occur on the ARM,
and replaced by the words

 "immediate base class" or "direct base"
or
 "non-immediate base class" or "indirect base"
or
 "immediate or non-immediate base class" or "direct or indirect base"

whichever is appropriate.

Another confusion is whether a class "has a function".
This makes the definition of abstract classes ambiguous,
and the wrong (IMHO) interpretation has disabled the use
of mixin programming techniques in two of the leading compilers.

A function can be "had" by a class in two different ways:
 1) declared explicitly
 2) inherited
and it is still confusing whether this applies to the name
of the function or the signature.
In addition, the virtualness of the fuction is important,
there is a sense in which a function can "have" a function
actually defined in a derived class.

The same applies to "default" constructors.
There is a difference between:

 Having an explicitly declared constructor X()
 Not having one declared but the compiler generates one.
 Not having one and the compiler doesn't generate one.
 Having a constructor with default arguments that resolves
 to the "default" constructor.

I am sure there are other cases (static :-) where the terminology
needs to be made more explicit.

Any others? Which have been addressed already?


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------