为什么我不能使用 GetProcAddress 在 DLL 中调用 C++ static class 工厂方法？

Question

I'm trying to load a hypothetical plugin with the following header:

#ifndef _DLL_H_
#define _DLL_H_

#if BUILDING_DLL
# define DLLIMPORT __declspec (dllexport)
#else /* Not BUILDING_DLL */
# define DLLIMPORT __declspec (dllimport)
#endif /* Not BUILDING_DLL */


class DLLIMPORT DllClass
{ 

  public:

    virtual ~DllClass(void);
    static DllClass* getPCFilter(); 
    virtual int Process(int a, int b);

  protected:

    DllClass();
};


#endif /* _DLL_H_ */

And my host code does:

HINSTANCE hinstDLL;
hinstDLL = LoadLibrary(L"PCFilter.dll");

if(hinstDLL)
{
    typedef DllClass*(*Factory)();
    Factory fun1;

  fun1 = (Factory)GetProcAddress(hinstDLL, "DllClass::getPCFilter");

The dll opens but the GetProcAddress is not finding the static factory method. Am I not supposed to be able to do it this way?

I've tried getting rid of the static method and instead, after the class declaration, doing the following:

extern "C" DLLIMPORT void* getPCFilterInstance()
{
    return (void*)new DllClass();
}

But then, when compiling the host source, the linker complains:

In function `getPCFilterInstance'::
[Linker Error] undefined reference to `_imp___ZN8DllClassC1Ev'

This I can solve by linking to the.a lib. But isn't the idea of the DLL to not need to link at compile time?

Answer 1

You ignore the fact that the function name will be decorated ("name mangling") or not at all visible in the DLL interface (under the given name). To my knowledge GetProcAddress doesn't do any name demangling, the linker however does (when statically importing a DLL with exported classes).

Best practice is to my knowledge to supply a factory function that has an undecorated name and a predefined calling convention much as COM prescribes it (see DllGetClassObject ).

Note: I should add that depending on the compiler/linker used, the decorated ("mangled") names will vary. Different compilers, different rules. Therefore they may not even be compatible amongst each other without considerable tinkering.

Edit: concerning the question:

But isn't the idea of the DLL to not need to link at compile time?

Well, yes and no. On Windows the whole process is somewhat different from the process in unixoid systems. The loader will take care of resolving dependencies and so on, but the point is that there are two ways of loading a DLL. One is by statically importing a DLL in which case the name resolution is done before your program gets to run (or fails before that) and the other is to load the DLL dynamically by means of LoadLibrary and friends and then resolve the function address with GetProcAddress . The latter has one variation (supported by the linker) called delay-loading. Ultimately it is still just the second method.

It is possible that delay-loading offers exactly what you want, by having the linker care about the names to resolve and still being able to handle failure of loading the DLL or resolving a name at runtime.

Answer 2

You can use extern "C" statement to export your function with the same name as you've declared it in the code - otherwise it will get mangled by the c++ compiler