views:

60

answers:

3

Hello,

I am having a strange problem that no pure virtual function is exporting from a DLL. DLL compiles and outputs as .dll file to the directory . But it doesn't produce .lib file.

If I give definition and it no longer remians as pure virtual, after that happily it creates .lib file.

I need to implement factory pattern for which I need to seperate interfaces and implementations. My factory implementation and other interfaces that use wanted .dll(of whome .lib file is not producing) need to use that exported function and when I use those functions they produce linking errors...

such as "error LNK2011: unresolved external symbol "public:......."

Have any one idea how to export pure virtual functions so that they can be implemented for other exe's and dll's

Regards Usman

+6  A: 

Hi, following link will clarify you doubts

Using dllimport and dllexport in C++ Classes

Not necessary to export class with only virtual/inline functions

Ravi shankar
I think the second link qualifies as a dup of this question.
T.E.D.
+3  A: 

When you export something from a DLL you are creating an externally-visible name for something concrete in that DLL - a defined function or class. Without this, the link step for importing projects (those that reference that DLL) cannot resolve all required references to functions and classes in the exporting DLL.

For pure virtual functions, there is no concrete 'thing' in the exporting DLL: no linkable name can exist to resolve an external call to a pure virtual function - if there were, it would by definition not be pure. In this case, all that's needed is a declaration in a compile-time accessible header file of the pure virtual function, so that importing EXEs or DLLs know how to override it with a concrete function.

Steve Townsend
A: 

In C++, you can define a pure virtual method. For example:

// T.hpp
class T
{
   public :
      virtual void doSomething() = 0 ;
      // etc.
} ;

.

// T.cpp
void T::doSomething()
{
}

// etc.

Now, with the dllexport/dllimport specifier added to the T class, you doSomething method will be exported.

The point of defining the body of a pure virtual method was to make sure the user would override the method, while still offering a default implementation.

My own use of this pattern is to avoid a crash when, for some reason, the virtual method is called before it exist, or when it does not exist anymore (i.e., in the constructor or the destructor of the base abstract class). In debug mode, it will launch the debugger (::DebugBreak() Win32 API function) and in release mode, it will silently do nothing.

But this pattern can also be used to solve your problem, if you really need to export your pure virtual functions.

paercebal
Personally I think a crash is prefereable to silently doing nothing when the client programmer screws up.
John Dibling
@John Dibling: I agree, but at least, overloading the pure virtual methods lets the user choose. As far as I am concerned, I would log the problem, and then throw a runtime exception with the message "You called this method, which is wrong, blah blah blah".
paercebal