Member Avatar for snyp

hi,

i am not really that good at c++.

i have created an application which dynamically loads dll's as types of 'plugin'

the problem i am trying to overcome is linking back to code in the application from the dll.

i am currently within the scope of a function of the dll. i have passed a void * parameter to the dll's function and then typecast that void * to a pointer of a class; a class which i have declared in a header file and included in the dll's code for reference.

note: this may seem like an over-complicated way of achieving something, but the method has been implemented to conform with skeletal frameworks to generalise all plugins.

typecasting the pointer is not a problem, and i can access variables within the class and read/write from/to them. the problem is with calling functions of the class from the dll.

i will try to illustrate this;

application class.h
class CExample
{
public:
int variable;
void function();
}

application class.cpp
void CExample::function()
{
return;
}

dll function.cpp
#include class.h

void CDll::other_function(void *pointer)
{
CExample *classPointer = (CExample *)pointer;

classPointer->variable = 0; // this is ok
classPointer->function(); // this won't link!
}

i am using visual studio 2008, which gives the linker error LNK2019 - unresolved external symbol "public: void __thiscall CExample::function(void)"

i have read somewhere that this means the linker has no concept of the implementation of the class. the class is declared in the application and i have no static library (.lib) to import into the dll.

the basic conceptual question i need help with is this; how can i execute the function in the application, when calling from the dll?

any help would be really appreciated with this,

thanks all

  • 2 Contributors
  • 3 Replies
  • 309 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Ancient Dragon

Dani AI

Generated

Short answer: the DLL link fails because calling a non-virtual C++ method emits a link-time reference to the method symbol (hence LNK2019), while reading/writing a data member only uses a compile-time offset so it works. ’s void* cast lets you touch the object memory, but a call to a concrete member function requires that the function be provided to the DLL at link/load time.

Two practical patterns that avoid exporting the app’s concrete method symbols:

  • Put the shared implementation (or at least the API) in a module both can link to (a static .lib or a shared DLL). This is the simplest, most robust fix — as suggested.

  • Keep the implementation in the EXE but expose behavior through a stable, header-only interface or callback table that the DLL uses at runtime. Example interface pattern:

/* HostInterface.h */
struct IHost {
    virtual void DoWork() = 0;
    virtual ~IHost() {}
};

/* plugin export (extern "C" to avoid C++ name mangling) */
extern "C" __declspec(dllexport) void PluginRun(IHost* host)
{
    host->DoWork();
}

Alternative (C-style callback):

typedef void (*HostCallback)(void* context);
extern "C" __declspec(dllexport) void PluginRun(HostCallback cb, void* ctx) { cb(ctx); }

Notes and cautions

  • Use extern "C" for plugin entry points so names aren’t mangled.
  • Avoid passing STL objects or managing memory across module boundaries unless you control CRT/runtime settings for every module.
  • Building all modules with the same compiler and runtime options reduces ABI surprises.
  • Exporting symbols from an EXE is possible but awkward; restructuring to use a shared interface or a library is usually cleaner.

Either the interface/callback approach or moving the implementation into a shared module will eliminate the LNK2019 and keep your plugin scheme flexible.

Recommended Answers

All 3 Replies

Member Avatar for Ancient Dragon

So the implementation code for the class is in the application program and not the DLL? Sounds backwards to me, and when compiling the DLL it is not possible for the compiler to resolve the class references. I think you need to redesign something and put the class implementation code either in the DLL or a lib that the DLL can link with. c++ classes can be easily exported from a DLL just like any other function.

Member Avatar for snyp

So the implementation code for the class is in the application program and not the DLL? Sounds backwards to me, and when compiling the DLL it is not possible for the compiler to resolve the class references. I think you need to redesign something and put the class implementation code either in the DLL or a lib that the DLL can link with. c++ classes can be easily exported from a DLL just like any other function.

it's good advice, and i decided to export code to make another type of dll plugin, which will contain the class. i had hoped not to do this, and only have one type of plugin; for this reason i asked my question.

i am surprised that you say something can't be done.. nothing is impossible :)

thanks for your reply squire.

Member Avatar for Ancient Dragon

>>i am surprised that you say something can't be done.. nothing is impossible

I don't pretend to be God. Read this thread.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.