Вызывается чистый виртуальный метод

Ответ 1

Проблема заключается в том, что Director::manageWorker вызывается в конструкторе экземпляров workerVariant:

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

Предположительно getThreadID() не является чистой виртуальной функцией или вы бы (надеюсь,!) получили ошибку компилятора, чтобы не переопределять ее в workerVariant. Но getThreadID() может вызывать другие функции, которые вы должны переопределить, но вызывается в абстрактном классе. Вы должны дважды проверить определение getThreadID(), чтобы убедиться, что вы не делаете ничего неприятного, что будет зависеть от дочернего класса до его правильной инициализации.

Лучшим решением может быть разделение этой многоэтапной инициализации на отдельный метод или на разработку Director и baseWorkerClass, чтобы у них не было такой взаимозависимости времени инициализации.

Ответ 2

Чистая виртуальная функция означает, что член, который является чистым в базовом классе, вызывается до запуска конструктора потомка. В программах с несколькими потоками это прямо или косвенно означает конструктор базового класса. В многопоточной программе это также может произойти, когда конструктор запускает поток в конструкторе, а система выполняет поток до того, как завершит конструктор.

Ответ 3

Не видя полного кода, я бы поставил под угрозу, что вы выходите из границы блока памяти, на который указывает workerPtrArray. Это, безусловно, имеет смысл, поскольку он жалуется на то, что называется чистая виртуальная функция. Если разыменованная память - это мусор, тогда среда выполнения вообще не может ее понять, и происходят странные вещи.

Попробуйте помещать утверждения в критические места, где вы разыгрываете массив, чтобы убедиться, что индексы имеют смысл. То есть ограничьте до 4 работников и убедитесь, что идентификатор меньше 4.

Ответ 4

Во время инициализации классы только частично построены. В частности, конструкторы должны быть выполнены из самого предкового класса вверх, так что каждый конструктор производного класса может безопасно обращаться к своим базовым членам.

это означает, что vtable частично построенного класса не может находиться в конечном состоянии - если виртуальным методам было позволено вызывать производные классы, эти методы будут вызываться до того, как был вызван конструктор классов.

Это означает, что при построении чистые виртуальные функции фактически являются чистыми виртуальными. Современные компиляторы С++ становятся лучше поймать это, но его во многих случаях "похоронить" незаконный вызов таким образом, что компилятор не замечает ошибку.

Мораль истории: не делайте ничего в своем конструкторе, который будет вызывать виртуальную функцию. Он просто не будет делать то, что вы ожидаете. Даже если это не чисто.

Ответ 5

Я не видел, чтобы вариантный класс строился в любом из ваших образцов кода. Вы уверены, что идентификатор передан в пределах диапазона для рабочего массива? Кроме того, вы строите объекты с помощью "новых", верно? Если вы построили объект в стеке, он зарегистрировался бы с директором, но после того, как конструктор вернет объект, он будет немедленно уничтожен, но Директор сохранит его указатель на объект, который был в стеке.

Кроме того, ваш деструктор baseWorkerClass должен быть виртуальным вместе с destructor workerVariant, чтобы убедиться, что они вызываются при удалении массива baseWorkerClass.

Из моего комментария к другому вопросу рассмотрите возможность использования std::vector вместо двойного указателя. Это легче поддерживать и понимать и устраняет необходимость поддерживать массив.

Кажется, вы добавили лишний слой абстракции. Я не думаю, что идентификатор должен быть частью интерфейса подкласса. Я думаю, что что-то вроде этого может работать лучше для вас:

class baseWorkerClass
{
public:

    baseWorkerClass(int id) :
        id( id )
    {
    }

    virtual ~baseWorkerClass()
    {
    }

    int getThreadID(){ return id; };
    virtual int getSomeVariable() = 0;

protected:
    int id;
};

class workerVariant : protected baseWorkerClass
{
    public:

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

    virtual ~workerVariant()
    {
    }

    int getSomeVariable()
    {
        return someVariable;
    }

protected:
    int someVariable
};

Ответ 6

Не можете ли вы случайно получить доступ к объектам после их разрушения? Поскольку во время уничтожения указатели vtable постепенно "откатываются", так что записи vtable будут указывать на методы базового класса, некоторые из которых являются абстрактными. После удаления объекта память может быть оставлена ​​так же, как и во время деструктора базового класса.

Я предлагаю вам попробовать инструменты отладки памяти, такие как valgrind или MALLOC_CHECK_ = 2. Также в unix довольно легко получить стек для таких фатальных ошибок. Просто запустите приложение под gdb или TotalView, и в этом месте ошибка будет автоматически остановлена, и вы можете посмотреть на стек.

Ответ 7

Я получил это сообщение об ошибке один раз, и, хотя он не относится к конкретному случаю апеллянта, я добавляю это в надежде, что он может быть полезен другим:

Я исправил проблему, выполнив чистую сборку.