6

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?

Community
  • 1
  • 1
phlipsy
  • 2,899
  • 1
  • 21
  • 37
  • 1
    The C Standard doesn't specify an ABI either. In fact, all the issues you complain about can apply to C just as much as to C++. –  Aug 05 '09 at 13:49
  • Yes, it is worth noting that the standard is generally set by the OS, and may or may not have anything to do with what its C compilers do. On Windows it is stdcall. – T.E.D. Aug 05 '09 at 14:03
  • @Neil. The C standard has a well defined ABI. That is why C is the GLUE between so many other languages. – Martin York Aug 05 '09 at 17:00
  • @martin Please point out (para reference) where the C Standard describes such an ABI? –  Aug 05 '09 at 19:07
  • @LokiAstari, no sorry, it just seems that way. An example why it could go wrong - different C compilers could define a pointer differently, maybe a 32-bit v 64-bit. An int could be 32 bits in one compiler but 64 bits in another. Arguments can be pushed on the stack in order, or in reverse order (eg MS's stdcall v cdecl calling convention). In practice this is not a problem, but it could be as there is nothing explicitly defined. – gbjbaanb Jul 24 '12 at 21:32
  • @gbjbaanb: You need to understand what ABI means before you comment. As 'Neil Butterworth' points out (Anon above) It is not defined at the standard (I had that bit wrong). But it is well defined at the platform level. What you are pointing out is architectural differences. But two C compilers on the same machine will use the same ABI. Unfortunately this does not hold for C++ as there is no ABI defined. That is why C is standard glue code between languages. – Martin York Jul 24 '12 at 22:27

4 Answers4

6

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.

Éric Malenfant
  • 13,938
  • 1
  • 40
  • 42
  • 1
    I sort of agree with the first bullet. However, the situations where the audience is small, homogeneous and under your control enough for this to apply are going to be fairly rare outside of development on a single executable. – T.E.D. Aug 05 '09 at 14:02
  • @T.E.D.: By "development on a single executable", do you mean "plugins that work with a single executable" or "one, single, monolithic executable with no plugins at all"? – Éric Malenfant Aug 05 '09 at 14:50
  • I was mostly thinking of the latter, but the former would probably qualify – T.E.D. Aug 05 '09 at 17:43
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.

Fabio Ceconello
  • 15,819
  • 5
  • 38
  • 51
1

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.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
0

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...

stsquad
  • 5,712
  • 3
  • 36
  • 54