Topic: deferred virtual overloading


Author: kcline@sun132.dsccc.com (Kevin Cline)
Date: 1995/05/02
Raw View
In article <3o4abe$3ev@keystone.intergate.net> scherrey@intergate.net (Benjamin Scherrey) writes:

> Notice that howdy() is declared virtual in class A whereas
> cheerio is declared virtual in class B when it is being
> overloaded. I was expecting to get B::cheerio called in both
> cases just like I got A::howdy because of the virtual mechanism.
> I've not been able to find any information about the rules for
> deferred virtual declarations so I don't understand why it works
> this way.

There is no such thing as a "deferred virtual declaration".

Indeed, I would think that anyone who went through the
> effort to declared an overloaded method virtual that they would
> do so specifically to ensure that the new method be called. I
> can't think of a situation where one would want otherwise - can you?
>
> I appreciate any comments regarding this issue. What are the odds
> of getting this behavior changed?
>

The chances of getting this changed are nil.

You said that the function cheerio() would not be polymorphic for
objects of class A, and that's what you got.  Either declare
A::cheerio() virtual, or don't make B a subclass of A.

When the compiler sees:
 foo(A& a) {
  a.cheerio();
 }
it decide what to do according to information about class A.  If
cheerio() is not virtual, then the compiler calls A::cheerio without
considering any run-time information.  If cheerio() is virtual, then
the compiler generates a call through the virtual dispatch table, and
the result depends on the run-time type of a.





--
Kevin Cline






Author: scherrey@intergate.net (Benjamin Scherrey)
Date: 1995/05/01
Raw View
Consider the following program:
--------------------------- cut here -------------------------
#include "iostream.h"

class A
{
public:

    virtual ~A( void ) {;}

    virtual const char* howdy( void ) const
    {
        return Text1;
    }

    const char* cheerio( void ) const
    {
        return Text2;
    }

private:

    static const char* Text1;
    static const char* Text2;

};

const char* A::Text1 = "A::howdy() being called!";
const char* A::Text2 = "A::cheerio() being called!";

class B : public A
{
public:

    const char* howdy( void ) const
    {
        return Text1;
    }

    virtual const char* cheerio( void ) const
    }
        return Text2;
    }

private:

    static const char* Text1;
    static const char* Text2;

};

const char* B::Text1 = "B::howdy() being called!";
const char* B::Text2 = "B::cheerio() being called!";

class C
{
public:

    void printRef( const A& a )
    {
        cout << "printRef:" << endl;
        cout << a.howdy() << endl;
        cout << a.cheerio() << endl;
    }

    void printPtr( const A* a )
    {
        cout << "printPtr:" << endl;
        cout << a->howdy() << endl;
        cout << a->cheerio() << endl;
    }
};

void main( void )
{
    cout << "Start." << endl;
    B b;

    C c;

    c.printRef( b );
    c.printPtr( &b );
    cout << "End." << endl;
}
----------------------------- cut here -------------------------

I get the following output:

Start.
printRef:
B::howdy() being called!
A::cheerio() being called!
printPtr:
B::howdy() being called!
A::cheerio() being called!
End.

----------------------------- cut here -------------------------

  Notice that howdy() is declared virtual in class A whereas
cheerio is declared virtual in class B when it is being
overloaded. I was expecting to get B::cheerio called in both
cases just like I got A::howdy because of the virtual mechanism.
I've not been able to find any information about the rules for
deferred virtual declarations so I don't understand why it works
this way. Indeed, I would think that anyone who went through the
effort to declared an overloaded method virtual that they would
do so specifically to ensure that the new method be called. I
can't think of a situation where one would want otherwise - can you?

  I appreciate any comments regarding this issue. What are the odds
of getting this behavior changed?

  thanx & later,

      Ben Scherrey
      Proteus Technologies, Inc.