spitzak@mizar.usc.edu (William Spitzak) writes:

...

>3. The more I thought about it, the more convinced I am that the
>proper way to do single inheritance is to do *exactly* the same
>thing as though you put the parent's declarations in the child.
>Thus derived should act exactly like I copied the foo(A) line.  Does
>anybody agree?

I have seen a little of the debate on this issue, and tend to
agree with the ARM on this point. Declaring a function within a
scope hides ALL overloaded functions with the same name. This is
covered in section 13.1.

David Sachs writes:

>I have seen a little of the debate on this issue, and tend to
>agree with the ARM on this point. Declaring a function within a
>scope hides ALL overloaded functions with the same name. This is
>covered in section 13.1.

I have been unable to determine from the working papers and the ARM
exactly how this rule should apply to operator function names.  It seems
that declaring an operator+() in class scope does not hide overloaded
operator+()'s that are declared at the top level, neither user-defined
ones nor intrinsic (built-in) ones.  I gather this because section 13.4.2
of the June 1 1993 working paper says "for any binary operator @,
x@y can be interpreted as either x.operator@(y) or operator@(x,y).  If
both forms of the operator function have been declared, argument matching
determines which, if any, interpretation is used."  Thus if a class
has declarations of a member function f and an operator @, the
expression "x @ y", when it occurs in the body of a member function
of the class, is treated differently from the expression "f(x,y)".
In the former case, @ does not hide operator@'s declared in surrounding
scopes, and argument matching is used to resolve ambiguities.  In the
latter case, the declaration of f hides f's declared in surrounding
scopes.  Naturally it would wreak havoc if the declaration of operator+
in class scope mean that expressions like "2+3" would no longer be
valid within member functions of the class.

Am I reading these rules correctly?  Is there no means of hiding an
operator declared in a surrounding scope?

-Luddy Harrison

In article <2oq28e$a48@fsgi01.fnal.gov>,
David Sachs <b91926@fsgi01.fnal.gov> wrote:
>spitzak@mizar.usc.edu (William Spitzak) writes:
>
>...
>
>>3. The more I thought about it, the more convinced I am that the
>>proper way to do single inheritance is to do *exactly* the same
>>thing as though you put the parent's declarations in the child.
>>Thus derived should act exactly like I copied the foo(A) line.  Does
>>anybody agree?
>
>I have seen a little of the debate on this issue, and tend to
>agree with the ARM on this point. Declaring a function within a
>scope hides ALL overloaded functions with the same name. This is
>covered in section 13.1.

I see the ARM's point on this issue, but I've been why it disallows using
access adjustment to get out of it.  E.g., I want to be able to say:

class B;

class A {
  public:
    //...
    void foo(int);
    void foo(A);
    void foo(B);
};

class B {
  public:
    //...
    A::foo;
    void foo(A);
};

With the effect of class B overriding foo(A) and still getting foo(int)
and foo(B).  The ARM specifically disallows this usage, but I don't see the
rationale behind it at all...  The arguments in favor of name hiding have
to do with accidentally getting base class members.  If I've put an explicit
access adjuster in, I'm effectively asking for base class members to be
treated as if they were local.

- Brad
------------------------------------------------------------------------
+ Brad Daniels                  | "Let others praise ancient times;    +
+ Biles and Associates          |  I am glad I was born in these."     +
+ These are my views, not B&A's |           - Ovid (43 B.C. - 17 A.D.) +
------------------------------------------------------------------------

In article <CoGIpy.9Dp@biles.com>, daniels@biles.com (Brad Daniels) wrote:
> >I have seen a little of the debate on this issue, and tend to
> >agree with the ARM on this point. Declaring a function within a
> >scope hides ALL overloaded functions with the same name. This is
> >covered in section 13.1.
>
> I see the ARM's point on this issue, but I've been why it disallows using
> access adjustment to get out of it.  E.g., I want to be able to say:
>
> class B;
>
> class A {
>   public:
>     //...
>     void foo(int);
>     void foo(A);
>     void foo(B);
> };
>
> class B {
>   public:
>     //...
>     A::foo;
>     void foo(A);
> };

The new "using" feature (part of namespaces) will do this:

   class B {
     public:
       //...
       using A::foo;
       void foo(A);   // hides A::foo(A) but not A::foo(int) or A::foo(B)
   };


Bill Gibbons
bgibbons@taligent.com

Okay, I know I have seen this discussed before, but I finally ran
into it in my code: (note that constructors and implementation of
A and B are missing from this example)

Class A;
Class B;

Class base {
public:
 char foo(A) {return 'A';}
 char foo(B) {return 'B';}
};

Class derived : public base {
 // no derived foo(A)
 char foo(B) {return 'C';}
};

void main() {
 derived x;
 A a;
 cout << x.foo(a) << '\n';
}

The above program will not compile.  If I add a cast from B to A then
it prints 'C'.  I expected the above to print 'A'.

1. My best guess for any kind of excuse for the above behavior is that
if there was a cast from B to A (there wasn't in my example) then the
programmer "might" want to call the derived function.  Is this really
the reason for this?

1a. If so, would it be possible to detect that no cast from B to A is
possible and then inherit the foo(A) function?

2. My compiler (SGI) produces a warning message when class derived
is defined *only* if both foo's are virtual.  If the above behavior
is correct, I would prefer this warning always.  Is there a reason
for this behavior?

3. The more I thought about it, the more convinced I am that the
proper way to do single inheritance is to do *exactly* the same
thing as though you put the parent's declarations in the child.
Thus derived should act exactly like I copied the foo(A) line.  Does
anybody agree?



--
 _      ______ _______ ______________________________
I_)o|| [_ ._ o|_ _  _.|  spitzak@mizar.usc.edu
I_)||| __]|_)||_ /_(_||< spitzak@sunova.d2.com
----------|------------------------------------------