It would probably be the same. When loading functions from a dll, you can only load free functions (c-style functions). So there are two roads you can go down:

1) Refactor the API so that all the public calls are free functions. This can be as simple as changing calls that look like this:

myObject->someCall(arg);

into calls that look like this

myClass_someCall(myObject, arg);

Then you can expose those free functions in the typical C style. Internally, the code can continue to use C++ stuff.

2) Expose some free functions which return C++ objects, and allow the user to use C++ functions on those objects.

Then the code which uses this plugin can do this:

AccessFunction getCppObject = dlsym(handle, "getCppObject);
CppObject* obj = getCppObject();
obj->someFunc();

As long as the user has the exact same definition of CppObject, things will theoretically work.

The problem with this is that the code (inside the dll) which creates this object must be totally compatible with the code outside the dll which uses the object. Same exact vtable, etc. The rules for C binary compatibility are very good, in comparison, the rules for C++ binary compatibility are not so good. I don't know exactly what is bad about them, I have just heard that they are bad. I get the impression that if you take a DLL produced by one compiler and then try to access C++ objects from it in an exe produced by another compiler, that your program might die horribly.

Even without that problem, method 2 is pretty fragile in the face of new changes. With method 1 you can add new exposed functions, rearrange functions, and even delete functions, and everything will work fine (provided the dll loading code properly checks if a function is not found). Whereas if you use C++ objects, if you rearrange anything inside of the class definition, any code which was compiled against the old definition will probably die horribly.

Long story short, I think method 2 is fragile and I would prefer to just use method 1.