portable alternative to dllexport?

[C+/-]

I'm currently designing a plugin system for a game engine. I want all modules (Graphics, Physics, Etc.) to be in seperate dynamically linked libraries. I would like to be able to use the classes in the plugin inside the engine that loads the plugins. I would also like the plugins' classes to be able to derive (and use) classes from the engine.

I think MS VC++2005 can do something like this with __declspec(dllimport) and __declspec(dllexport), but I'm looking for something that is portable. If such a thing does not exist, is there a way to use some trick (like using a macro) so that only the macro has to be changed when porting the code to another platform?

Thanks,

[matsp]

How portable do you want it?
Compiles on most compilers under Windows?
Compiles on popular OS's such as Windows, Linux and Solaris?

For Windows, it appears that gcc and MS compilers support the __declspec() - so there's at least two compilers the "customer" can choose from.

It would be a good idea to define a macro like
#define DLLImport __declspec(dllimport)

so that anyone using another compiler will be able to replace it with whatever is right in that compiler.

If you want it portable to different OS's then you need to do more complex work, since shared libraries [a.k.a Dynamic Link Libraries] are not quite the same for different machines. However, since .so [Linux Shared Library Objects] are name-defined, the problem in Linux is much less - you can essentially just do

#ifdef LINUX
#define DLLImport
#define DLLExport 
#else
#define DLLImport __declspec(dllimport)
#define DLLExport __declspec(dllexport)
#endif

Is it your plan to supply the library as source or binary?

--
Mats

[C+/-]

I'd like it to be portable to popular OSs (linux, mac), and preferably also consoles. (The code may never be ported to a console or another platform at all, I just want to write it "right", you never know..)

so that anyone using another compiler will be able to replace it with whatever is right in that compiler.

The most important question, then, is: do all (well.. most) platforms support some method of importing classes (not just global functions!) with some kind of modifier, similar to dllimport? If that where the case it'd be just a matter of changing the macro depending on the platform.

I'm planning to supply the libraries (together with the engine) as binaries.

[matsp]

Well, as I explained above, Linux (and I believe *BSD uses the same technique) uses name-based shared libraries, so function names are the mechanism of "finding" the function in the shared library. Windows uses a numerical (index) based sharing. This makes sharing C++ objects harder, because you have to connect a C++ name to a number.

Classes are essentially global functions, but your "func" in

class a {
...
   void func();
};

a::func() {
...
}

gets renamed to something like a$$func@0v or some such by the compiler.

There are two problems with classes and DLL's:
1. If you use numeric exports, the calling function doesn't know the name of the function it calls, so if you get your numbers "mixed up", then you may call "func1" in the class, and end up in "func2" in your dll - because they got re-ordered or someone removed a function in the class, and now func2 is at func1's place.
2. If you supply a binary file, you need to make sure that you have "binary compatibility" within your header-file. This is a huge subject. Here's one of the first links I found: http://aegisknight.org/cppinterface.html

I hope this helps more than it confuses.

--
Mats

[C+/-]

Thanks,

I think maybe using the word "plugin" is wrong here. I'm not trying to create a way for external developers to create arbitrary additions to my program. What I want to accomplish is logical seperation of my code, with the ability to:
A) Change the working of the engine by changing what library is dynamically linked. For example, I might want to create a DirectX and OpenGL implementation of the graphics module, and be able to choose which one to use without recompiling.
B) Be able to distribute updates that only contain changed modules. So a security fix in the networking module should be fixable by distributing the fixed networking library.



Regarding problem 1:
This is not a problem with A. I just have to make sure that the functions are in the right order. It's not a problem with B either, as long as such an update does not add/remove functions.

Regarding problem 2:
I'm not sure I understand this, but isn't this problem alleviated if I recompile both the host (the app that dynamically links the libraries) and the libraries themselves on the other platform? Given that both can indeed be compiled there, there should be no problem, right?

Are my asumptions correct? In this case, would it be sufficient to use a macro for the dllexports, and change that macro when porting?

[matsp]

Yes, binary compatibility (BC) is only a "problem" if you don't want to rebuild the app after changing some DLLs. Which may well be what your "customer" would like to do if for example a 1 million games have been sold with a security hole in the network function, and you want to fix it up. Not that this particular fix should, usually, require an update that breaks BC. But say for example you produce a new library that has extended functionality, and also improvements in performance in existing functions. Now, your customer may want to give this new version to all game company customers as a "freebie" - but not rebuild the existing games that is unchanged.

You will also, of course, have to make sure that at all times the DirectX or OpenGL version of code works equivalently and in a "compatible way".

--
Mats