Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!cmcl2!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Summary: Pointers to virtuals, yes they work ...
Message-ID: <158@mole-end.UUCP>
Date: 30 Apr 89 07:41:58 GMT
References: <904@garya.Solbourne.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 33

> How does one get the address of the virtual function for an object, given
> a pointer to the object?
 
> 	B	*bp = new B ;
> 	A	*objp = (A*) bp ;
 
> 	fp = &objp->f ; // if objp is REALLY a *A, I want &A::f
> 	                // but if it's REALLY a *B, I want &B::f
 
>  I don't want   fp = &A::f  because I need the appropriate virtual function
>  to dispatch when the function call is made. ...  Or am I missing something
>  here?  If I do     fp = &A::f     and subsequently do a    (bp->*fp)()
>  will this somehow go through the virtual table and actually call   B::f   if
>  bp is REALLY a B* object pointer?  ...

It sure will.  Pointers to virtual members are themselves virtual and go
through the virtual tables.  How, you ask, is it done?  Take my word, you
don't want to know.  It's ugly.  Worse, it imposes a couple of extra
instructions of cost on every call-through-a-pointer-to-member-function if
the class has *any* virtual members (or perhaps its any virtual members whose
argument signatures match; I don't know for sure.)  The cost really isn't
that great.

One of the versions of cfront has a bug that causes it to generate code
which triggers error messages or warnings from the C compiler.  I don't
recall which version it is--it's been a long time since I had to deal with
the problem.  I had to work around it by creating a friend class whose
member functions' only job was to call the appropriate virtual functions
in the class hierarchy of interest.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile