What's safe for a C++ plug-in system?

问题:

Plug-in systems in C++ are hard because the ABI is not properly defined, and each compiler (or version thereof) follows its own rules. However, COM on Windows shows that it's possible to create a minimal plug-in system that allows programmers with different compilers to create plug-ins for a host application using a simple interface.

Let's be practical, and leave the C++ standard, which is not very helpful in this respect, aside for a minute. If I want to write an app for Windows and Mac (and optionally Linux) that supports C++ plug-ins, and if I want to give plug-in authors a reasonably large choice of compilers (say less than 2 year old versions of Visual C++, GCC or Intel's C++ compiler), what features of C++ could I count on?

Of course, I assume that plug-ins would be written for a specific platform.

Off the top of my head, here are some C++ features I can think of, with what I think is the answer:

• vtable layout, to use objects through abstract classes? (yes)
• built-in types, pointers? (yes)
• structs, unions? (yes)
• exceptions? (no)
• extern "C" functions? (yes)
• stdcall non-extern "C" functions with built-in parameter types? (yes)
• non-stdcall non-extern "C" functions with user-defined parameter types? (no)

I would appreciate any experience you have in that area that you could share. If you know of any moderately successful app that has a C++ plug-in system, that's cool too.

Carl

回答1:

Dr Dobb's Journal has an article Building Your Own Plugin Framework: Part 1 which is pretty good reading on the subject. It is the start of a series of articles which covers the architecture, development, and deployment of a C/C++ cross-platform plugin framework.

回答2:

You might also want to consider replacing the conventional plugin interface by a scripting interface. There are some very good bindings for several scripting languages in C/C++ that have already solved your problem. It might not be a bad idea to build on top of them. For example, have a look at Boost.Python.

回答3:

Qt has a very nice system for plugins that I've used in the past. It uses Qt's meta-object system to overcome many of the problems typically found when trying to develop C++ plugins.

One example is how Q_DECLARE_INTERFACE works, to prevent you from using an incompatible plugin. Another is the build key, to make sure you load the correct plugin for your architecture, OS, compiler. If you don't use Qt's plugin system, these are things you will have to worry about and invent solutions for on your own. It's not necessarily rocket science, and I'm not saying you'd fail at it, but the guys at Trolltech are pretty smart and have spent a while thinking about it, and I'd rather use what they created than reinvent the wheel myself.

Another example is that RTTI typically doesn't work across DLL boundaries, but when using Qt, things like qobject_cast which rely on the meta-object system do work across DLL boundaries.

回答4:

I think you are safe creating a plugin system based on:

• Packaging of plugin functionality into library (.dll, .so, etc.)
• Requiring that the plugin expose key C-language exports.
• Requiring that the plugin implement (and return a pointer/reference to) an abstract C++ interface.

Probably the most successful C++ plugin system: good old Adobe Photoshop. And if not that, one of the virtual synth formats such as VSTi etc.

回答5:

The book Imperfect C++ by Matthew Wilson has a nice info about this.

The advice in the seems to be: as long as you use the same (or equivelant) compiler, you can use C++, otherwise you're better of using C as an interface on top of your C++ code.

回答6:

ACE has a cross platform plug-in architecture.

Check out:

1. ACE DLL
2. ACE DLL Manager

I would suggest checking out the book
The ACE Programmer's Guide

回答7:

Firefox runs on XPCOM (http://www.mozilla.org/projects/xpcom/). It's inspired by Microsoft COM but it's multiplatform.

回答8:

I have my own game engine that has a C++ plug-in system.

I have some code in header files so it gets put into the plugin's compilation unit.

Larger functions that live in the main engine are called via an exported C function (plugin calls MyObject_somefunction(MyObject *obj) which in the engine just calls obj->somefunction()). If calling a C function is ugly for your taste, then with some header trickery, when the header is included in the plugin, have the member function #defined to call the C function:

#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif

Virtual functions either have to be pure or the code lives in the header file. If I'm not inheriting from a class and merely just instancing one, virtual function code can live in the engine, but then the class must export some C functions for creating and destroying the object that is called from the plugin.

Basically, the tricks that I have used, with the goal being to maintain total platform independence, just amount to C exports and header file tricks.