views:

26

answers:

2

Each of these classes are in separate dll modules:

class Base
{
public:
  virtual void foo();
  void bar();
};


class Derived : public Base
{
public:
  // override Base::foo()
  void foo();
};

In Other.cpp:

#include "Derived.h"

The module that contains Derived links with Base.lib (not shown are the export/import directives). The module that contains Other.cpp links with Derived.lib, but not Base.lib. Up to this point, everything works fine.

However, if I change Base::bar() to be virtual and do not make a change to Derived, then the linker complains when linking Other.dll:

Other.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Base::bar()" ...

The only solutions I have found is to override Base::bar() in Derived or to have Other.dll also link with Base.lib. Both solutions are not desired because they add client requirements when the server changes.

Any ideas on a better way to access/define the base class virtual methods in this scenario?

+1  A: 

What's happening is that virtual Base::bar needs to be in the vtable of a Derived, since there's no Derived::bar.

I don't understand your comment about "client requirements when the server changes". I don't see how base/derived maps to client/server. They're two independent dimensions to me.

MSalters
A: 

Thanks MSalters, that is pretty much the conclusion we have reached. It was also discovered that Other.cpp was instantiating a Derived. The factory pattern would be a good solution.

The client-server reference comes in to play when one is developing a component comprising Base as an SDK to a client who implements Derived (and/or Other). By the server making a change to Base, the client's build will be broken until Derived is also modified.

Of course, good API developers will not make API changes that would disrupt a client's build. Therefore, it is good to know that changing a Base function to be virtual is such a disruption.

Jason