Re: Wrong Virtual Function Called
reddys wrote:
Uli wrote:
Late binding is usually implemented by calling the n-th
function in the classes virtual function table. If you
change the meaning of the table (i.e. index n doesn't mean
fou anymore but barre) then your program fails like you
describe.
I assumed the client object vptr pointed to the head of the
vtable and the appropriate function name would be resolved.
However it seems as though the vptr stores information (i.e
call n-th function) based on the vtable layout when the client
was compiled. I thought or hoped that the function name
resolution would not need to have prior knoweldge of the
vtable layout.
Anyone know why?
Speed and simplicity. Name lookup is significantly slower and
more complicated than indexing into a table.
If the interface was non-virtual and extended a rebuild of the
client would not be necessary and linking (whether dynamic or
static) would resolve to the correct member function.
That's because the linker uses name lookup. The difference is
that for non-virtual functions, this name lookup is done once,
at link time; for virtual functions, it must be done every time
the function is called.
Certain clients were not exhibiting erroneous behaviour but
this must be because they were accessing a part of the vtable
which has not altered.
To confirm I believe dynamic linking is correct and resolving
to the correct vtable so this is not the issue. It's the late
binding vptr/vtable implementation mechanism which requires a
rebuild of all clients which instantiate any class in the
inheritance hierarchy whose virtual interface has changed.
Exactly.
Formally, you are violating the one definition rule. The
definition of the class seen by some client code (when it was
compiled) is not the same as the definition of the class seen by
other client code. This is undefined behavior.
Formally, any change in the class requires recompilation of all
code which uses the class. Even if the change is as simple as
adding a non-virtual private function or replacing an int with a
typedef'ed name which resolves to int. Anything else is
undefined behavior. In practice, you'll usually only get into
trouble if you add data members or virtual functions, or change
the signature of a function. But as far as the standard is
concerned, as soon as the sequence of tokens changes, or a
binding of any token changes, it's undefined behavior.
I appreciate your comments.
The usual rule is to keep the interface as simple as possible,
in order to minimize changes. Also, to use some sort of
versionning, so that a version mismatch will fail to load.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]