From: Robert C White Jr 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: Reply-To: rwhite AT bellatlantic DOT net NNTP-Posting-Host: client250-241-33.bellatlantic.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.