From:	Robert C White Jr <rwhite AT bellatlantic DOT net>
Newsgroups:	comp.programming,comp.os.msdos.djgpp
Subject:	Re: Undefined reference to virtual table
Date:	Mon, 28 Jul 1997 01:44:44 -0400
Organization:	Bell Atlantic Internet Solutions
Lines:	45
Message-ID:	<33DC31CC.161B@bellatlantic.net>
References:	<Pine DOT SOL DOT L3 DOT 93 DOT 970718181624 DOT 22501A-100000 AT bingsun3>
Reply-To:	rwhite AT bellatlantic DOT net
NNTP-Posting-Host:	client250-241-33.bellatlantic.net
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Thomas Happ XIII wrote:
> 
>         This is an oop c++ problem . . .
>         I have a class, Map, and a subclass, PicMap.  My Map class has no
> constructor, three virtual methods, and three non-virtual methods.  My
> PicMap class has a constructor with several arguments, a destructor,
> overrides of the three virtual methods in Map, and some of its own
> methods.  It compiles fine, but when I go to link, it says, ". . . in
> function Map::Map(void) . . . undefined reference to 'Map virtual table'".
> First of all, I didn't make a function Map::Map() (or even a function
> PicMap::PicMap()), but after the error I tried doing the former and it
> still said the same thing.  It was my understanding that the virtual
> method table of a subclass is identical to that of the parent class but
> with its own methods concatenated on the end, so where is this error
> coming from?
>                                         Tom

You haven't *quite* provided enough information.  The things most
notably are A) does Map have any ancestor classes? and B) does Map use
any data types with constructors?  C) what compiler are you using?

My "generic" advice is:

1: any class you intend to inherit from and use polymorphically (e.g.
referencing a PicMap from a Map pointer) where any of the child classes
will have a destructor, should have *virtual* destructors at the roots
of the class trees even if that destructor is empty.  This ensures the
correct destructor is always available to the system.

2: make sure that you re linking in definitions for all the non-pure
virtual functions in all the ancestor classes.  The "need not be defined
if never used" rule does not apply, occuring in any virtual table for
any type constitutes use (e.g. it needs to be resolved by the linker). 
Most link-time errors involving the virtual tables involves not having a
definition for a virtual function linked in (usually optimized out by
hand because of "I never call that" thoughts by the author)

3: check for any compile-time options that affect the placement of
virtual tables.  If you are doing multi-file builds whit these options
inconsistently set all sorts of things may go wrong.

4: if you are doing multi-file "make"s, check that all your dependencies
are correct.  One old module can really botch things badly.

Rob.

- Raw text -