2010-05-21 2 views
1

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

Если у меня есть следующий абстрактный интерфейс:

class IArpPacketBuilder 
{ 
public: 

    IArpPacketBuilder(const DslPortId& aPortId); 
    virtual ~IArpPacketBuilder(); 

    // Other abstract (pure virtual methods) here... 
}; 

и я его экземпляр так:

class DummyArpPacketBuilder 
    : public IArpPacketBuilder 
{ 

public: 

    DummyArpPacketBuilder(const DslPortId& aPortId) 
     : IArpPacketBuilder(aPortId) {} 
    ~DummyArpPacketBuilder() {} 
}; 

почему я получаю следующее сообщение об ошибке при компоновке?

Unresolved symbol references: 

IArpPacketBuilder::IArpPacketBuilder(DslPortId const&): 
    ppc603_vxworks/_arpPacketQueue.o 
IArpPacketBuilder::~IArpPacketBuilder(): 
    ppc603_vxworks/_arpPacketQueue.o 
typeinfo for IArpPacketBuilder: 
    ppc603_vxworks/_arpPacketQueue.o 
*** Error code 1 

IArpPacketBuilder является абстрактным интерфейсом, так что до тех пор, как я определить конструктор и разрушение в бетоне (производный) интерфейс, я должен быть тонкой, нет? Ну, похоже, нет.

ответ

5

У вас есть только объявлен конструктор и деструктор IArpPacketBuilder, не определенный их. Компилятор также нуждается в определениях. Обратите внимание, что C++ не имеет понятия абстрактного интерфейса - IArpPacketBuilder - простой старый класс, который содержит некоторые чистые виртуальные методы, что делает невозможным его непосредственное создание.

Так самое простое решение, чтобы обеспечить встроенные реализации:

class IArpPacketBuilder 
{ 
public: 

    IArpPacketBuilder(const DslPortId& aPortId) {} 
    virtual ~IArpPacketBuilder() {} 

    // Other abstract (pure virtual methods) here... 
}; 

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

class IArpPacketBuilder 
{ 
public: 

    IArpPacketBuilder(const DslPortId& aPortId) {} 
    virtual ~IArpPacketBuilder() = 0; 

    // Other abstract (pure virtual methods) here... 
}; 

IArpPacketBuilder::~IArpPacketBuilder() {} 
+0

Я смог наследовать этот интерфейс в другой библиотеке без проблем, поэтому не думал, что это будет проблемой. Нужно ли определять их в абстрактном интерфейсе? – LeopardSkinPillBoxHat

+0

@ Leopard, интересный. Я думал, что это не сработает - если вы явно объявите конструктор/деструктор, компилятор не будет автоматически генерировать его для вас автоматически. Обратите внимание, что C++ не имеет понятия _abstract interface_ - ваш класс является простым классом с некоторыми чистыми виртуальными методами, что делает невозможным его непосредственное создание. –

+0

Спасибо, я заработал, определяя тела ctor и dtor, но я до сих пор не могу понять, почему он работал в другой библиотеке, когда я не определил ctor и dtor. – LeopardSkinPillBoxHat

1

пытаются встраивать их - работает для меня, хотя не знаю, если это хорошее решение

+0

Вы имеете в виду предоставление встроенных реализаций в IArpPacketBuilder? – LeopardSkinPillBoxHat

+1

да, точно так же Питер ответил – XAder

2

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

Смежные вопросы