Why should I setup a plugin interface in c++ instead of c

Question

As a result of my previous questions I asked myself: Is it usefull at all to setup a C++ interface for a plugin system? The following points are speaking against it:

• No common ABI between different compilers and their versions, no common layout of the objects in memory
• No direct class export. You have to export factories and destructors. Problems arises if your objects are held by other objects which only delete them, for example smart pointers.
• Different implementations of the STL, you can't pass a std::list<T> to the plugin
• Different versions of used libraries like Boost

If you restrain yourself to the remaining parts of the C++ language you nearly end up with the "C subset". Are there any points speaking for using C++? How do the Qt-Toolkit solve the mentioned problems?

Remark: I'm referring mostly to the Linux system. Nevertheless I'm interested in solutions on other platforms.

Additional question: What are the problems using a C interface? The memory layout of structs? Which language parts of C should be avoided?

Answer 1

I think you are answering your own question there. There is nothing to stop you implementing a simple C plugin interface and allowing plugin writers to implement their plugin with C++ though. Just do try and learn from the mistakes made by the Netscape Plugin API...

Answer 2

Although this is more about the "how" than the "why", you may be interested in the (not yet)Boost.Extension library, as well as the author's blog on the topic.

For the "why" part, my 2 (Canadian) cents: It depends on the audience (the plugin writers) and on the richness of the interface between your application and its plugins:

• If the audience is large or heterogeneous, the limitations of a C++ plugin system (keeping the plugin side and the app side in synch with respect to compiler and library versions) gets impractical, and a C interface is more maintainable. If the audience is small, homogeneous, or under your control, these problems are not as significant.
• If the interface is rich (hand-waving on the precise meaning of "rich"), a C interface may get cumbersome to write, and the balance tilts on the C++ side.

However, the first criterion (the audience) is more important, and a C++ interface thus makes sense only if the audience is homogeneous and the interface significantly benefits from the expressiveness gains.

Answer 3

Generally it is a smart idea to write interfaces to some interface standard that can be counted on. That's why pretty much every OS provides such an interface. On most Unixes the C compilers use the same convention as the OS, so they call it the C calling convention. Windows has stdcall for this purpose.

If you try to use some compiler-internal calling interface, like C++'s, then you will fall prey to all the problems you mentioned. Even compiler updates are liable to hose you.

Answer 4

I once made in C++ the plugin interface for a system I developed and it was a big mistake. Feasible, but not practical at all. Today, I'd always make the interface purely in C, and as simple as I can. The benefits of these choices are really significant. And if your plugin writers want a C++ API, you can simply write a C++ wrapper that calls the C interface.

As an added bonus, if your plugin writers want an API in any other language, a C API will always be the easier to create bindings for.