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:
delete
them, for example smart pointers. std::list<T>
to the plugin 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 struct
s? Which language parts of C should be avoided?
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:
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.
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.
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.
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...
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.