Re: Bug? Where are these emitted?? (type_info, virtual table, etc)

[Todd Vierling <tv at pobox dot com>]

On Mon, 5 Oct 1998, Phil Edwards wrote:

:     DBR type_info node                  ./lib/libDBR.so
:     DBR type_info function              ./lib/libDBR.so
:     DBR virtual table                   ./lib/libDBR.so

: and then began the linker errors you saw above.  In desperate 
: experimentation, I made the base member fn pure virtual,
: 
: 	virtual int foo () const = 0;    // NOT implemented
: 
: and all was well.  Even though foo was never being called anywhere in client 
: code, since I hadn't gotten that far.

Without the = 0 clause, the compiler has to put in provision for having a
function foo() part of this class.  Hence the virtual table problem.

The compiler doesn't know, and in some cases *cannot* know, whether a
virtual function exists at compile time, so when it creates the virtual
function table for a superclass (...in anticipation of you _possibly_
calling the superclass's virtual methods), it tries to reference any that
are not pure virtual (= 0).  The virtual tables contain pointers to all
virtual functions for a class, regardless of whether you call them.

So, the compiled code assumes, with the non-pure-virtual foo(), that you
have declared the class somewhere with its virtual functions (and in turn,
its type_info information).

: Is this a problem with egcs 1.1, or am I violating the Standard?  The base 
: class was already pure due to the dtor, so an "impure" virtual in the base 
: class doesn't really make any sense, granted, but I didn't think it would 
: cause errors.  (I'm going to leave them pure virtual anyhow, in the spirit of 
: making more sense.)

Having them non-pure virtual is broken.  If the virtual function is not
pure, you must define it somewhere.

On Tue, 6 Oct 1998, Phil Edwards wrote:

: That's common behavior as I understand it.  Curious that the linker 
: complained about 'missing virtual table' and the contained type_info, but 
: never about a missing non-abstract impure virtual definition.  Perhaps it 
: just gives up after three missing defs?  (I've never found a way to study 
: linker design; they're complete black magic to me.)

This would require lots of Magic between the compiler and linker.  Virtual
functions in egcs compiled code are part of an tables of pointers to
functions and pointers to other (superclass) virtual function tables.

If any one of those pointers (such as the pointer to the table containing
the superclass's foo() above) cannot be resolved, that is a linker error.
The compiler has no way of knowing where that table is actually defined, and
the linker has no way of knowing which entry in the table could not be
resolved.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)