C++ Linking Errors: Undefined symbols using a templated class

Question

I'm getting some really wierd linking errors from a class I wrote. I am completely unable to find anything that will describe what is happening.

Visual Studio (Windows XP)

players.obj : error LNK2019: unresolved external symbol "public: __thiscall TreeNode::TreeNode(void)" (??0?$TreeNode@VPlayer@@@@QAE@XZ) referenced in function "public: __thiscall PlayerList::PlayerList(void)" (??0PlayerList@@QAE@XZ)

Xcode (OSX 10.5)

Undefined symbols: "TreeNode::~TreeNode()", referenced from: PlayerList::~PlayerList()in players.o

Header File: generics.h

class TreeNode : public BaseNode{
public:
    const static int MAX_SIZE = -1; //-1 means any size allowed. 
    const static int MIN_SIZE = 0;
    //getters
    int size() const;
    vector<C*> getChildren() const;
    //setters
    void setChildren(vector<C*> &list);
    //Serialization
    virtual void display(ostream &out) const;
    virtual void read(istream &in);
    virtual void write(ostream &out) const;
    //Overrides so SC acts like an array of sorts. 
    virtual C* get(int id) const; 
    virtual int get(C *child) const;
    virtual bool has(C *child) const;
    virtual C* pop(int id);
    virtual void push(C *child);
    virtual TreeNode& operator<< (C *child); //append
    virtual void remove(int id); //Clears memory 
    virtual void remove(C *child); //Clears memory 
    //Initalizers
    TreeNode();
    TreeNode(istream &in);
    TreeNode(long id, istream &in);
    TreeNode(BaseNode* parent, istream &in);
    TreeNode(long id, BaseNode* parent);
    TreeNode(long id, BaseNode* parent, istream &in);
    ~TreeNode();
    string __name__() const{ return "TreeNode"; }
protected:
    void clearChildren();
    void initalizeChildren();
    vector<C*> _children;
};

Code from a subclass of TreeNode

PlayerList::PlayerList() : TreeNode<Player>(){}
PlayerList::PlayerList(istream &in) : TreeNode<Player>(in){}
PlayerList::~PlayerList(){}

Answer 1

When you define your template in a .cpp file, you have to explicitly instantiate it with all the types / template parameters known the template will be used beforehand like this (put it in the .cpp file):

template class TreeNode<Player>;

If you don't know with which template parameters the template will be used, you have to put all the definitions into the header. like

template<typename T>
class TreeNode {
public:
   TreeNode() /* now, also put the code into here: */ { doSomething(); }
};

The reason is that when you are going to use the template from somewhere, the compiler has to be able to generate the code for that specific instantiation of the template. But if you place the code into a .cpp file and compile it, there is no way for the compiler to get its hands on the code to generate the instantiation (except when using the infamous export keyword, which is only supported by very few compilers).

This is also an entry in my C++ Pitfalls answer: What C++ pitfalls should I avoid?

Answer 2

Well you are declaring ~TreeNode(), but are you defining it?

When you declare the destructor you stop the compiler from generating one for you, but you must define it somewhere, even if it is empty.

If your intent was to have an empty destructor you have two options:

-Remove the declaration of ~TreeNode() entirely, and rely on the self generated destructor -Define it as empty. Inling would be very nice here, IE. ~TreeNode() {};

Answer 3

The compiler is complaining about not finding an implementation of the destructor. As pointed before, if you do declare the destructor, the compiler will not automatically generate one for you.

To the suggestion by David Reis of either removing or providing an empty destructor, I would clearly go for the second. If your class is meant to be derived (you have virtual methods) then you should provide a virtual destructor, even if it is empty (same applies to BaseNode).

If you depend on the compiler generated version and user code deletes a derived object through a pointer to a base class whose constructor is not virtual then the derived object's destructor will not be called, possibly leaking resources.