DLL convenience wrapper

[Core Xii]

I'd like a cross-platform convenience interface for explicitly linking DLLs at run-time. I'd like to implement plugin architectures in my applications but am faced with an overwhelming complexity and complete lack of information for actually achieving this. Easy-to-use functions for loading DLLs at specified file paths, and calling functions from them.

[Laurent]

It's very easy, if you want an example just have a look at the Ogre engine source code, there's a very simple class (with macros for each OS) which does this job.

Basically, the functions to call are :
- LoadLibrary, GetProcAddress, FreeLibrary on Windows
- dlopen, dlsym, dlclose on Linux (not 100% sure of the names)
- no idea on MacOs

[Core Xii]

I'm sure it's easy, but I wouldn't care writing countless compiler conditions for the different operating systems. I'd appreciate it if you did it, but I'll take a look at Ogre, thanks.

[Laurent]

So you're lazy and want me to write your class ? Or is it an interesting feature that you'd love to see in SFML for all users ?

[Core Xii]

Not lazy, just inexperienced. I only recently discovered SFML and it looks more favorable over SDL. This would be the icing on the cake. I don't need it right now and I don't know how useful other people find it, but it would indeed be a useful thing to have in the future.

After all, the convenience of easy-of-use and cross-platform compatibility out-of-the-box is exactly why I would (will?) use this library.

[bullno1]

It's already cross-platform and it already has a C wrapper.

After all, the convenience of easy-of-use and cross-platform compatibility out-of-the-box is exactly why I would (will?) use this library.

Sorry but I think most of the people find that linking to a dynamic library during compile time(let the compiler generate the loader) is easier than using platform-dependent code to load it during runtime.

[Core Xii]

It's already cross-platform and it already has a C wrapper.

I'm sorry, what are you talking about?

Sorry but I think most of the people find that linking to a dynamic library during compile time(let the compiler generate the loader) is easier than using platform-dependent code to load it during runtime.

Easy is good. But the problem here is that compile-time linking does not allow you to provide a plugin system.

[Wizzard]

You will find oftentimes that using a scripting language is better than creating a plug-in system via DLLs.
In such cases where you would think that you would need to interface with DLLs, you can usually load DLLs with the scripting language.
For an example of a scripting language that has DLL support, check out Lua and it's require function.

[Laurent]

It's already cross-platform and it already has a C wrapper.

He doesn't want to dynamically link SFML, he wants to have a class in SFML which can load dynamic libraries at runtime to build plugin systems.

I don't need it right now and I don't know how useful other people find it, but it would indeed be a useful thing to have in the future.

Actually, I'm still hesitating to add this kind of class. For sure it would be useful, but so are so many classes, and I don't want SFML to become a big / bloated general cross-platform framework. I'd like to stay focused on multimedia.

[SirJulio]

You will find oftentimes that using a scripting language is better than creating a plug-in system via DLLs.

I agree.

If you can design a dll-like plugin system, you can write your own multi-platform loader (the 3 fonctions that Laurent gave above (AFAIK Mac and linux use the same)).

A scripting module would be a very interresting thing, but i don't even know how this can be done (genericity, portability, integration with current modules ....). This is indeed a huge work, but scripting languages (python, lua, or others) are easy to use, it would be a nice feat for SFML. =)

[Core Xii]

Actually, I'm still hesitating to add this kind of class. For sure it would be useful, but so are so many classes, and I don't want SFML to become a big / bloated general cross-platform framework. I'd like to stay focused on multimedia.

Well you don't have to include it by default, make it optional.

I don't like the idea of having to use scripting, it's slow, and one would have to learn said language. It would also mean the source for the plugins would be exposed, not necessarily an acceptable condition in all situations.

I took a look at Ogre but the functionality is too entangled with the rest of the library for me to separate. I certainly don't want to link to Ogre for that alone.

[Wizzard]

I don't need it right now and I don't know how useful other people find it, but it would indeed be a useful thing to have in the future..

So, you do need it? You should tell us the plans you have with this, because right now it doesn't seem too likely that were going to do it for you.

[Core Xii]

I have two applications for it that I can immediately think of. A plugin system for an editor defining data and exports (I'm making a vector-based graphics program that'll also be used as a level editor for several games), and full modability for a big project via callbacks.

If I actually had it so easy and at my disposal, I'm sure I'd find good use for it.

[Laurent]

I took a look at Ogre but the functionality is too entangled with the rest of the library for me to separate

No, there's a tiny DynLib class which just does this job. You just have to ignore the log and error handling.

http://ogre.svn.sourceforge.net/viewvc/ogre/trunk/OgreMain/include/OgreDynLib.h?view=markup
http://ogre.svn.sourceforge.net/viewvc/ogre/trunk/OgreMain/src/OgreDynLib.cpp?view=markup

[Core Xii]

Right but I'd need to link to Ogre. Bit of a big an engine to link to for one class.