c++ plugin : Is it ok to pass polymorphic objects?

问题:

When using dynamic libraries, I understand that we should only pass Plain Old Data-structures across boundaries. So can we pass a pointer to base ?

My idea is that the application and the library could both be aware of a common Interface (pure virtual method, = 0). The library could instantiate a subtype of that Interface, And the application could use it.

For instance, is the following snippet safe ?

// file interface.h

class IPrinter{
    virtual void print(std::string str) = 0;
 };

-

// file main.cpp

int main(){
    //load plugin...
    IPrinter* printer = plugin_get_printer();
    printer->print( std::string{"hello"} );
}

-

// file plugin.cpp (compiled by another compiler)

IPrinter* plugin_get_printer(){
    return new PrinterImpl{};
}

回答1:

This snippet is not safe:

• the two sides of your DLL boundaries do not use the same compiler. This means that the name mangling (for function names) and the vtable layout (for virtual functions) might not be the same (implementation specific.

• the heap on both sides may also be managed differently, thus you have risks related to the deleting of your object if it's not done in the DLL.

This article presents very well the main challenges with binary compatible interfaces.

You may however pass to the other side of the mirror a pointer, as part of a POD as long as the other part doesn't us it by iself (f.ex: your app passes a pointer to a configuration object to the DLL. Later another DLL funct returns that pointer to your app. Your app can then use it as expected (at least if it wasn't a pointer to a local object that no longer exists) .

回答2:

The presence of virtual functions in your class means that your class is going to have a vtable, and different compilers implement vtables differently.

So, if you use classes with virtual methods across DLL calls where the compiler used on the other side is different from the compiler that you are using, the result is likely to be spectacular crashes.

In your case, the PrinterImpl created by the DLL will have a vtable constructed in a certain way, but the printer->print() call in your main() will attempt to interpret the vtable of IPrinter in a different way in order to resolve the print() method call.