C abi

hi,

I am in the process of developing a dynamic plugin system for an application written in C++.
Requirements:

- support Win, Linux, OSX (x86 and x64)
- support at least C/C++ plugins (bonus: delphi and other native languages)

Ergo i am perfectly happy with plain Functions exported by the main application and used by plugins. No templates, no OOP; though i would like to pass structs back and forth, if possible.

I read this excellent article:

http://philippe.ameline.free.fr/tech...nFramework.htm

which describes a few interesting concepts.


Most notably, it states that if i wrap my Function- and Struct definitions in <extern "C">, i can not only use function pointers, but also exchange pointers to structs (and make use of them) with "virtually all C compilers".


I find that hard to believe. Is the C ABI really that standardized? What about x64? Alignment?


The relevant quote from the article:

Quote:

---

The ultimate in compatibility is to just forget about C++ and expose a pure C API. C is compatible in practice between all compiler implementations.

---

What kind of control do you have over the plugin development? Do you have to support a mix of compilers or can you limit support to a single compiler (version) per platform?

What kind of SDK do you want to provide for the plugin developers?

I was doing a porting project from Linux/Unix to Windows, which involved a simple plugin system. It took me some googling and reading to find a working solution. Look at this thread:
http://forums.codeguru.com/showthrea...-library-MinGW
You can find a simple example there, which works in with several different platforms (Windows, Linux, FreeBSD, MacOSX). You can use it as a starting point for your solution.

Johannes

probably the simplest form of "plug in" you can provide third parties is a scripting language, an in that case LUA is a popular choice because it's small, it's fast, it's versatile and it's free with a very liberal license.
The big advantage is that the plug ins will run on any system

With everything else, your api will be system dependant and the plug ins will need to be compiled for various systems if the creators wish to support all of your supported platforms as well.

You will need to do a lot more than just define some functions as "extern C" to get any system going that is actually doing anything. And no, the C API isn't standardized to the degree that what you said will "just work". You will also need to explicitely define the calling convention, because you can't otherwise guarantee what the compiler defaults to.

@D-Drmmm

Quote:

---

What kind of control do you have over the plugin development?

---

very little, so i cannot limit compilers.
What do you mean by what kind of SDK?

@johannes
thanks, will do!

edit:
how'd i miss that thread...? :S

@OReubens

Quote:

---

explicitely define the calling convention,

---

yeah, but i can do that. :)

Separate compilations for the different OSs are ok.

I will also look into scripting langages, but compiled plugins are a requirement.

(Google repeatedly brings me to SWIG - www.swig.org, but it seems to me it wraps my entire application to be used from *within* scripting languages like python...i'd need it the other way around. :))

you will need:
access points INTO your application so the external plug in can call your app to request it to do stuff or request certain variables.
and you will need a way to convey those to the plug ins.

you will need to add code so you can load an external plugin, manage it, and "start" the code in the plugin. Depending on what kind of plugins you're after

you will also need regular calls back into the plugin everytime you have an event the plugin needs to know about.

You also need to give the plugin a chance to do cleanup

you need to actually clean up/dispose of plugins


The above will take many hours of work. And it'll require your own code to follow strict rules so it works nice alongside the plugins.
And then I'm not even talking about the headaches that result of ill written plugins that do things you didn't see coming.

Thanks, but i am aware of all that. :)

The core question was whether this quote from the article:

Quote:

---

The ultimate in compatibility is to just forget about C++ and expose a pure C API. C is compatible in practice between all compiler implementations.

---

a) is actually true.
b) is also true for cross-platform environments (win,lin,osx)
c) holds up fro x64


My tests so far seem to work out fine, but i am still having hard time believing it's that easy.

1) yes, but this won't help you (much). This is more about making it possible for one exe to call into a dll made by someone else. It doesn't really do a whole lot for you. If you expose all your entry points via dll, it may be a simple way for you to expose those, but it's not the easiest way for others to write a plugin that way.

2) no, other platforms have different ways of loading / handling binaries. So while the exporting of functions may be standard, this doesn't in any way or form help you with the plugin thing.

3) only in so far as it exposes those to other 64 bit binaries. making a 32bit plugin talk to a 64 application or vice versa will take quite a bit of flexing (and coding).

1) but it does. If i can exchange a pointer to a struct and make use of it in both my application and the plugin dll (linked by a different compiler).
What would be an easier way, shipping a header + a (compiler dependant) .lib file?

2) I was just wondering whether the article exclusively referred to windows compiler regarding the compatibility, but apparently this is also true for linux and osx.

3) I think it's ok to have a x64 and a x86 version of a plugin.

Thanks for the reply!