class DLLEXPORT Button
{
boost::function<void> onClick;
boost::function<void> onMouseOver;
boost::function<void> onMouseRelease;
//etc;
}
class player
{
public:
void play();
void stop();
};
player thePlayer;
//use a factory because of restriction in point 3.
Button* myButton = Factory::createButton();
myButton->onClick = boost::bind(&player::play, &thePlayer);
Quote:Original post by GamerSg
Ok, so it should work. But now im in a dilemma, if i implement my events using Boost, users of my DLL will also need to download boost to use it. Because my headers contain
boost::function<void> onClick;
And they will probably need boost::bind to bind events.
This not only increases dependancies for the user but could also introduce problems because of binary incompatibilities because of different compiler settings/boost versions.
Any advice if i should still use boost?
Quote:Original post by Gluber
On the Memory issues:
You have to make sure your DLLs and EXE use the Multithreaded DLL or Multithreaded Debug DLL runtime libs.. Without those every module will get its own private heap ( managed by the CRT of VC ) and thus allocating in a DLL and freeing the pointer in another one ( or the Exe ) would cause an exception ( since it can't find the pointer in its own heap ) ..
If you use the Multithreaded DLL family you will get a single heap for all your in process modules and thus you can safely pass around pointer new/delete them whereever you want without problems..
On the design side.. Have you considered using boost::signal ? Its exactly what you would need for events in a GUI library in my opinion... Very similiar to .NET delegates.
You can register multiple handlers to a single signal and call the signal like a function.... Very easy to use and very powerful.
Quote:
You're going to have compiler compatibility issues with DLLs anyway, and there isn't much you can do about it (and if there is, let me know!). You'll probably have to ship a DLL per compiler anyway, so compatibility shouldn't be an issue.
Quote:Original post by GamerSg
Ill have to disagree with this, because i see programmers using the same DLL with many different VC versions/MingW with no problems.
Example
1) OpenGL (The one provided by MS/drivers from ATI/nVidia)
2) OpenAL
3) FMod
4) DirectX
etc..
Quote:Original post by phantomOpenGL, OpenAL and FMod are pure C interfaces.Quote:Original post by GamerSg
Ill have to disagree with this, because i see programmers using the same DLL with many different VC versions/MingW with no problems.
Example
1) OpenGL (The one provided by MS/drivers from ATI/nVidia)
2) OpenAL
3) FMod
4) DirectX
etc..
While I cant speak for the others both OpenGL and OpenAL use C name mangling, which is standised, C++'s name mangling scheme and vTable layout ISNT, as such a native C++ library is going to probably explode if you try to use one compiled on one compiler with another.
class com_class { struct { void (*virtual_function)(com_class *p); } *vtable;public: inline void virtual_function() { vtable->virtual_function(this); }};
