Implementing A Plugin System in C or C++ [closed]

Answer 1

This may not be what you're looking for, but you could embed a scripting language in your application, such as Lua. Lua was designed to be embedded in other programs and used as a scripting language for writing plugins. I believe it's fairly easy to add the Lua interpreter to your program, though I don't know Lua so I can't vouch for how effective of a solution this would be. Others with more experience with Lua, please add comments about your experience with embedding Lua in another application.

This would, of course, mean that your plugins need to be written in Lua. If you don't like Lua then the de-facto standard Perl, Python and Ruby interpreters are all written in C, and can be embedded in a C program. I know of a number of programs that use these languages as scripting language extensions.

However, I don't know what you're looking for, as your question is a little vague. Perhaps more information about what you want people to be able to do with said plugins would be appropriate. For some tasks, a full-blown scripting language may be a bit overkill.

Answer 2

In C (and I think C++ too although I haven't done it myself), this is most typically done using dynamically loaded modules. The API:s for such are platform-dependent.

On POSIX (Linux), you use the dlopen() family of functions. Basically you build your plugin separately, then load it at run-time, look up its symbols by name, and can then call them.

For Win32, there is LoadLibrary() which does something very similar, you build your code into a DLL.

For a handy wrapper that makes all of these easy and transparent, check out GLib's GModule API.

Answer 3

This podcast on plugin architectures might also be interesting.

Answer 4

It's best to use a framework like ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) that shields you (as good as possible) from platform specific coding.

ACE contains a plugin framework that is based on shared libraries that you can use to create dynamically assembled applications.

For a higher level abstraction check out CIAO (http://www.cs.wustl.edu/~schmidt/CIAO.html) the Open Source C++ implementation of the CORBA Component Model.

Answer 5

I have written an article about how to implement a plugin system using Dynamic Linking Libraries. The article is written from the point-of-view of a Windows programmer but the technique can be applied to a Linux/Unix type environment.

The article can be found here: http://3dgep.com/?p=1759

The main point is, you should create a "common" DLL that is implicitly linked by both the main application (the core application) and by the plugin implementations. The plugins can then be explicitly linked and loaded dynamically at run-time by the core application.

The article also shows how you can safely share static (singleton) instance of a class across multiple DLLs by using the "common" DLL.

The article also shows how you can export a "C" function or variables from a DLL and use the exported functions in the application at run-time.

Answer 6

In the '92/'93 time frame I worked on a plugin architecture for Aldus PageMaker, which was coded in C++. PageMaker was built on a C++ OOP framework called VAMP, which assisted its portability between Mac OS and Windows.

So we tried to use the features of C++ to build a plugin architecture. This proved to be very problematic for C++ classes due to the so-called brittle base class problem. I proceeded to write a paper that was published in journals and that I presented at OOPSLA '93 in a reflection workshop. I also made contact with Bjarne Stroustrup at a Usenix conference in Portland and proceeded to dialog with him for several months, where he championed the issue of dealing with the brittle base class problem on my behalf. (Alas, other issues were deemed more important at that time.)

Microsoft introduced the COM/DCOM system and for that platform that was looked on as a viable solution to the problem. C++ could be used as an implementation language for COM via abstract classes used to define COM interfaces.

However, these days developers shun away from COM/DCOM.

In contrast, NeXT devised a plugin architecture using Objective C in the early 90s in the NeXT Step framework. Today that lives on vibrantly in Mac OS X on Apple's computers and important platforms such as the iPhone.

I submit Objective C enabled solving the plugin problem in a superior manner.

I personally regard the brittle base class problem of C++ to be it's most fatal flaw.

If were building a plugin architecture with the C-based family of languages, would do so using Objective C.