Framework, Exporting functions, and classes

[detlion1643]

I have a pretty substantial C# program currently. I have been pondering a rewrite of it to C++ using SDL/OpenGL. Currently, the C# program has a separate project within it (Framework) that encompasses a lot of classes to it (IE: BaseControl, DerivedButton, DerivedLabel, etc). There is also a plugin structure to load .dll's. The premise is that others can make a "Panel" and layout the exposed controls to it. The core program then renders any active "Panel".

For the past couple of weeks I have been doing tons of research on a plugin structure/architecture within C++.
http://www.codeguru.com/cpp/misc/misc/plug-insadd-ins/article.php/c3879/Plugin-Architecture-Framework-for-Beginners.htm
http://blog.nuclex-games.com/tutorials/cxx/plugin-architecture/
http://www.abstraction.net/ViewArticle.aspx?articleID=67
And various StackOverflow pages.

I have yet to understand if I can keep my design from the previous project. So far I am led to believe that I can only export functions that are not within a class or else the names become mangled.

Is there a design where I can give users the ability to link to my framework project and use exposed classes (label, button, etc) so they can make their own panels that I can render.

The plugin structure ideally only needs to expose an Initialize method which I can call. Each plugin can do whatever in that method, such as creating a "Panel" and some buttons on it. Then the core program would load that panel and when it's displayed it would render it. If I can't expose controls with correct names how can the framework be used by others?

Currently a C# plugin could do something like this after referencing the framework:

Public void Initialize()
{
    Panel p = new Framework.Controls.Panel("Name");
    Button b = new Framework.Controls.Button("Name", x, y, w, h);
    p.AddControl(b);
    Framework.PanelManager.Load(p);
}

The reason for moving to C++ is to become cross-platform compatible. I know there is Mono and such but I'd rather go lower level and not rely on others having to use Mono. Plus my controls via OpenGL code are fun!

EDIT: Forgot to add that I am aware of the difference between loading .dll's and .so's. I found this which is a great reference: http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

[LB]

Have you looked at how other C++ libraries (e.g. SFML) accomplish it?

[detlion1643]

I previously haven't. So I went ahead and looked at various header/cpp files of SFML and I couldn't see anywhere where they exported functions.

I then went ahead and looked through some of the SDL headers and they use the "extern "C"..." approach but I didn't notice any classes.

I still can't understand how the approach of classes falls within this.

Am I thinking too object oriented still?

Maybe I'll have a look at Mono with some C# OpenGL wrapper (maybe OpenTK)...

[LB]

detlion1643 wrote:

So I went ahead and looked at various header/cpp files of SFML and I couldn't see anywhere where they exported functions.

Really? I see files literally named "Export.hpp". They use macros everywhere so that the library support a wide array of operating systems.

[detlion1643]

My apologies, I went looking through the src folder instead of the include folder. I found the "Export.hpp" file and looked at it. It defines a variable to use as export/import just as I have done.

I then made a new file to test it and found out that the exported names are still mangled.

#if defined(FRAMEWORK_EXPORTS)
    #define FRAMEWORK_API __declspec(dllexport)
#else
    #define FRAMEWORK_API __declspec(dllimport)
#endif 

#include "../Export/Export.h"
class FRAMEWORK_API Configuration
{
    public:
        void InitializeConfiguration();
};

And here is the resulting Export Definition File:

EXPORTS
    _Z23InitializeConfigurationv @1

[LB]

Do you actually know what those #define statements do? They're just macros, not magic. In specific, if your code compiled it was because you never enabled FRAMEWORK_EXPORTS - if you do, you will get errors because FRAMEWORK_API_EXPORT is not expanded to valid code.

This is where all the "magic" happens:
https://github.com/LaurentGomila/SFML/blob/master/include/SFML/Config.hpp#L113-L156
Notice the compiler-specific definitions for the macros. There is no portable way to do this (yet).

[helios]

Mangling is prevented only by prepending extern "C" to global functions.
This pattern:

#if defined(FRAMEWORK_EXPORTS)
    #define FRAMEWORK_API __declspec(dllexport)
#else
    #define FRAMEWORK_API __declspec(dllimport)
#endif 

is only used when you want to use the same header for the DLL and the DLL user. It won't, by itself, prevent mangling, but you can use it with extern "C" functions.