Pure Virtual Method Called

jakogut picture jakogut · Jan 30, 2010 · Viewed 37.7k times · Source

EDIT: SOLVED

I'm working on a multi-threaded project right now where I have a base worker class, with varying worker classes that inherit from it. At runtime, the worker classes become threads, which then perform work as needed.

Now, I have a Director I've written which is supposed to maintain an array of pointers to all of the workers, so that it can retrieve information from them, as well as modify variables within them later.

I did this by creating a pointer to a pointer of the base class:

baseWorkerClass** workerPtrArray;

Then in the constructor of the Director, I dynamically allocate an array of pointers to the base worker class:

workerPtrArray = new baseWorkerClass*[numWorkers];

In the constructor of each worker thread, the worker calls a function in the director which is meant to store the pointer of that worker in the array.

Here's how the director stores the pointers:

Director::manageWorker(baseWorkerClass* worker)
{
    workerPtrArray[worker->getThreadID()] = worker;
}

Here is an example of a worker variant. Each worker inherits from the base worker class, and the base worker class contains pure virtual functions which should exist in all worker variants, as well as a few variables which are shared between all workers.

class workerVariant : protected baseWorkerClass
{
    public:

    workerVariant(int id)
    : id(id)
    {
        Director::manageWorker(this);
    }

    ~workerVariant()
    {
    }

    int getThreadID()
    {
        return id;
    }

    int getSomeVariable()
    {
        return someVariable;
    }

    protected:

    int id;
    int someVariable
};

Then the baseWorkerClass looks something like this:

class baseWorkerClass
{
public:

    baseWorkerClass()
    {
    }

    ~baseWorkerClass()
    {
    }

    virtual int getThreadID() = 0;
    virtual int getSomeVariable() = 0;
};

After each worker variant is done initializing, I should end up with an array of pointers to baseWorkerClass objects. This means I should be able to, for example, get the value of a given variable in a certain worker using its ID as the index to the array, like so:

workerPtrArray[5]->getSomeVariable(); // Get someVariable from worker thread 5

The problem is that this code causes a crash in a Windows executable, without any explanation of why, and in Linux, it says:

pure virtual method called
terminate called without an active exception
Aborted

I could've sworn I had this working at some point, so I'm confused as to what I've screwed up.


Actual unmodified code that has the problem:

Worker variant header: http://pastebin.com/f4bb055c8
Worker variant source file: http://pastebin.com/f25c9e9e3

Base worker class header: http://pastebin.com/f2effac5
Base worker class source file: http://pastebin.com/f3506095b

Director header: http://pastebin.com/f6ab1767a
Director source file: http://pastebin.com/f5f460aae


EDIT: Extra information, in the manageWorker function, I can call any of the pure virtual functions from the pointer "worker," and it works just fine. Outside of the manageWorker function, when I try to use the pointer array, it fails.

EDIT: Now that I think about it, the thread's entry point is operator(). The Director thread is created before the workers, which may mean that the overloaded parenthesis operator is calling pure virtual functions before they can be overridden by the child classes. I'm looking into this.

Answer

John Feminella picture John Feminella · Jan 30, 2010

The problem appears to be that Director::manageWorker is called in the constructor of workerVariant instances:

Director::manageWorker(baseWorkerClass* worker) {
    workerPtrArray[worker->getThreadID()] = worker;
}

Presumably getThreadID() isn't a pure virtual function or you would have (hopefully!) gotten a compiler error about not overriding it in workerVariant. But getThreadID() might call other functions which you should override, but are being invoked in the abstract class. You should double check the definition of getThreadID() to make sure you're not doing anything untoward that would depend on the child class before it's properly initialized.

A better solution might be to separate this sort of multi-stage initialization into a separate method, or to design Director and baseWorkerClass such that they don't have this sort of initialization-time interdependency.