Why do I need to configure the plugin interface in C ++ instead of c

Question

As a result of my previous questions, I asked myself: is it useful to configure the C ++ interface in general for the plugin? The following points speak to him:

• There is no common ABI between different compilers and their versions, there is no general layout of objects in memory
• No direct export of classes. You must export plants and destructors. Problems arise if your objects are stored by other objects that only delete them, for example, smart pointers.
• Various STL implementations, you cannot pass std::list<T> plugin
• Different versions of libraries used, such as Boost

If you hold back on the rest of the C ++ language, you almost get a "subset of C". Are there any points for using C ++? How does the Qt-Toolkit solve these problems?

Note. I mean mainly the Linux system. However, I am interested in solutions on other platforms.

Additional question: what are the problems using the C interface? Memory layout struct s? Which language parts of C should be avoided?

Answer 1

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

For the “why” part, my 2 (Canadian) cents: it depends on the audience (plugins) and on the richness of the interface between your application and its plugins:

• If the audience is large or heterogeneous, the limitations of the C ++ plug-in system (supporting the plug-in side and the application side in synchronization with the compiler and library versions) become impractical, and the C interface is more convenient to maintain. If the audience is small, homogeneous or under your control, these problems are not so significant.
• If the interface is rich (manual marking for the exact value “rich”), the C interface can become cumbersome to write, and the balance tilts on the C ++ side.

However, the first criterion (audience) is more important, and therefore the C ++ interface makes sense only if the audience is homogeneous, and the interface benefits greatly from increased expressiveness.

Answer 2

I once made a plugin interface in C ++ for a system that I developed, and it was a big mistake. Perhaps, but not practical. Today, I 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 developers need a C ++ API, you can simply write C ++ - a wrapper that calls the C interface.

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

Answer 3

This is usually a smart idea to write interfaces with some interface standards that you can count on. That is why almost every OS provides such an interface. On most Unixes, C compilers use the same convention as the OS, so they call this the C-call convention. For this purpose, Windows has stdcall.

If you try to use some internal interface for the compiler, for example C ++, then you will fall prey to all the problems you talked about. Even compiler updates can put you on.

Answer 4

I think you are answering your own question. Nothing prevents you from implementing a simple C plugin interface and letting plugin developers implement their C ++ plugin. Just try to learn from the mistakes made by the Netscape Plugin API ...