In article <9408171609.AA08603@tdat.elsegundoca.ncr.com>,
Stan Friesen <swf@ElSegundoCA.NCR.COM> wrote:
:This is not necessarily true.  It depends on how smart the compiler is
:about optimizing.   In a case like this, the compiler could easily
:recognize that D::foo() is a simple forwarding funcion, and simply
:install a pointer to B::foo() in the virtual table, along with the
:necessary pointer conversion information (which is necessary anyway
:for inherited virtual functions, and so costs nothing extra).
:
:Of course, this is just a "quality of implementation" issue, not
:a standards issue.
:
:--
:swf@elsegundoca.ncr.com  sarima@netcom.com
:
:The peace of God be with you.

Yes, but I think that it *should* be a standards issue, rather than an
optimizing issue.  Thanks, by the way, to Mr. Clamage for the namespace
solution.  I don't exactly understand how the solution works, but then
again, I haven't dug into namespaces yet either...(no time and no compiler
that implements it :-()

Stephen Gevers
sg3235@shelob.sbc.om

I have the following code:

class B {
public:
 virtual int foo();
};

class D : public B {
public:
 void foo (int);
};

Now D::foo(int) hides B::foo().  As far as I know, there is no way to
"unhide" B::foo().  If I create an inline function:
 int D::foo() { return B::foo(); };
doesn't the compiler still have to make a copy of this function somewhere
so that it can be called through the virtual tables?  Given that, I am
forced to pay a penalty of an extra function call on virtual accesses.

This situation came about because the original definition of "D" was not
derived from "B".  Much code would have to be changed if D::foo was
renamed.  I think that you should be able to "unhide" a base class' function
in the same way that you make a private base class' public function public
in the derived class:

class D : public B {
public:
 void foo (int);
 int B::foo();
};

This would make the function visible and maintain B::foo in the virtual
tables.

If this has already been solved, what is the syntax?  If not, is there a
good reason not to solve it by the above suggestion or some other method?

Stephen Gevers
sg3235@shelob.sbc.com

In article s6e@ritz.cec.wustl.edu, jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) writes:
>I have the following code:
>
>class B {
>public:
> virtual int foo();
>};
>
>class D : public B {
>public:
> void foo (int);
>};
>
>Now D::foo(int) hides B::foo().  As far as I know, there is no way to
>"unhide" B::foo().  If I create an inline function:
> int D::foo() { return B::foo(); };
>doesn't the compiler still have to make a copy of this function somewhere
>so that it can be called through the virtual tables?  Given that, I am
>forced to pay a penalty of an extra function call on virtual accesses.

Right. The addition of namespaces solves the problem, since you can
explicitly import D::foo into the namespace of B. No extra code gets
generated. Coming soon (well, eventually) to a compiler near you.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <32r4cu$s6e@ritz.cec.wustl.edu>, sg3235@shelob.sbc.com writes:
|>
|> Now D::foo(int) hides B::foo().  As far as I know, there is no way to
|> "unhide" B::foo().  If I create an inline function:
|>  int D::foo() { return B::foo(); };
|> doesn't the compiler still have to make a copy of this function somewhere
|> so that it can be called through the virtual tables?  Given that, I am
|> forced to pay a penalty of an extra function call on virtual accesses.

This is not necessarily true.  It depends on how smart the compiler is
about optimizing.   In a case like this, the compiler could easily
recognize that D::foo() is a simple forwarding funcion, and simply
install a pointer to B::foo() in the virtual table, along with the
necessary pointer conversion information (which is necessary anyway
for inherited virtual functions, and so costs nothing extra).

Of course, this is just a "quality of implementation" issue, not
a standards issue.

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.