Error undefined reference to vtable

> I was creating the derived class method definitions in a cpp file
> and couldn’t get the project to progressively compile correctly.
> At my first method definition, a default constructor,
> the compiler kept spitting out this error message:

this is perhaps the most obscure error message that gcc (actually the linker) spits out, but the reason is simple:

the compiler has to put the (one and only one) vtable for a class into some object file or the other. it puts it into the object file for the translation unit where the definition of the first non-pure-virtual out-of-line virtual member function is present. if there is no such definition, you get this rather unhelpful linker error message.

you would be able to progressively compile the code even if a non-pure virtual function is not defined, but to be able to link without errors, every such function must have a definition (at least a stub). and to prevent the non-creation of a v-table by the compiler, at least one of the non-pure virtual functions will have to be defined out-of-line.

gcc has a faq about this: http://gcc.gnu.org/faq.html#vtables

> Am I to assume that the example in the book, as regards the inline feature
> of a derived class destructor, is in error.
i think it is not a particularly good book, but in this case neither the book nor the compiler is in error.
if you define the destructor inline, and void VintagePort::Show() const out-of-line, the error will go away. there has to be at least one out-of-line definition of a non-pure-virtual function.

note: the microsoft compiler (as well as several other compilers) does not require this; it instantiates a v-table with internal linkage in *every* translation unit in which such a header (all non-pure virtual functions are inline) is included. this violates the c++ one definition rule for v-tables, but as always, folks at redmond tend to value pragmatism highly. and they do give you __declspec(novtable) to suppress the proliferation of v-tables.

Thank you very much, this has certainly cleared things up. In a way, I’m glad I came across this problem, hopefully it won’t catch me out again, when progressively compiling.

Hi … I hope this helps someone out there….

I’m using netbeans with the C++ plugin in linux. I got the vtable error, and after a long time I figured out the solution..

basically the class I was trying to use was not added into the project. The class files (.cpp, .h) were in the project folder, and i was editing the files, etc… but they just wouldn’t compile because they weren’t added into the project.

so just right click the project, select «add existing items» and choose the file and add the files to the project… now it should compile, fingers crossed

I have also seen this with GCC 4 when a virtual destructor is missing a body
eg:
virtual ~MyClass(void);
should be:
virtual ~MyClass(void){};

I have also seen this with GCC 4 when a virtual destructor is missing a body
eg:
virtual ~MyClass(void);
should be:
virtual ~MyClass(void){};

Also if you declare a virtual constructor but forget the ‘~’ in its definition, e.g.:
virtual ~A(); // declaration in .h file
A::A() {} // .cpp implementation missing ~ in function name

Also if you declare a virtual constructor but forget the ‘~’ in its definition, e.g.:
virtual ~A(); // declaration in .h file
A::A() {} // .cpp implementation missing ~ in function name

That doesn’t make sense… Removing ‘~’ makes your function a ‘Constructor’ instead of a ‘Destructor’…

The only difference between the .H version and the .CXX version is that you don’t put ‘virtual’ in the .CXX file…

I’m self studying from the book, C++ Primer Plus Fifth Edition, by Stephen Prata. The following relates to Chapter 13, Page 699, Programming Exercise #4. One task is to write the derived class method definitions based upon the given prototypes. The following are the said prototypes.

class Port
{
    private:
        char *brand;
        char style[20];     // i.e. tawny, ruby, vintage
        int bottles;
    public:
        Port(const char *br = "none", const char *st = "none", int b = 0);
        Port(const Port &p);            // copy constructor
        virtual ~Port() { delete [] brand;}
        Port & operator=(const Port &p);
        Port & operator+=(int b);
        Port & operator-=(int b);
        int BottleCount() const {return bottles;}
        virtual void Show() const;
        friend ostream &operator<<(ostream &os, const Port &p);
};

class VintagePort : public Port
{
    private:
        char * nickname;            // i.e. The Noble, or Old Velvet, etc.
        int year;                   // vintage year
    public:
        VintagePort();
        VintagePort(const char *br, int b, const char *nn, int y);
        VintagePort(const VintagePort &vp);
        ~VintagePort() {delete [] nickname;}
        void Show() const;
        friend ostream & operator<<(ostream &os, const VintagePort & vp);
};

You will note that the base class destructor is virtual. That the derived class destructor is implemented inline.

I was creating the derived class method definitions in a cpp file and couldn’t get the project to progressively compile correctly. At my first method definition, a default constructor, the compiler kept spitting out this error message:

The line number was pointing to my derived class constructor definition. I did some googling around and came across this workaround. I removed the inline effect of the derived class destructor, made that into a method definition in the cpp file and presto, compilation succeeded.

Am I to assume that the example in the book, as regards the inline feature of a derived class destructor, is in error. Are there any other explanations.

This error also arises in gcc if a class is inherited from a class in non included library but added include file.

Thanks. Procrastes’s answer helped. Virtual destructor was missing a body and the error was gone when I fixed it.

Dont put virtual if you dont need.

Had the same problem.
Solved by removing the macro definition for LIB_HAS_DLL.
When building an application for cross-compiling, people usually include a MACRO BLOCK similar to the one show below and use function linkage such as

LIB_FUN void myfunc();

by defining LIB_HAS_DLL this becomes __declspec(dllimport) void myfunc();
adding LIB_BUILD_DLL it becomes __declspec(dllexport) void myfunc();

removing -DLIB_HAS_DLL from the cmdline causes the function to be auto-import and mingw resolves the vtable.
/* DEFINITION for DLL Linkage */
#ifdef LIB_HAS_DLL
# ifdef LIB_BUILD_DLL
# if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__)
# define LIB_FUN __declspec(dllexport)
# else
# define LIB_FUN
# endif
# else
# if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__)
# define LIB_FUN __declspec(dllimport)
# else
# define LIB_FUN
# endif
# endif
#else
# define LIB_FUN
#endif