class ISprite : public IRefCounted
{
public:
virtual ITexture *GetTexture()=0;
virtual Size2<unsigned> GetSize()=0;
virtual Point2<float> GetCentre()=0;
virtual void SetCentre(Point2<float> centre)=0;
virtual void Draw(Point2<float> pos)=0;
}
Writing a dll that is not compiler dependent
Author
I need to create a set of OO dlls that are not dependent on which compiler they were built on, or the compiler that the exe thats using them was built with. Eg I may build the dlls with VC9, but the person using them may use gcc.
This seemed a simple enough to begin with, just dont use any compiler specific features, and take into account they use diffren CRT's with memory management.
Then I found out that C++ doesnt garuntee any sort of binary compatibility in dlls past extern "C" functions :(
So the question is, how can I create a dll containing classes (which can be dynamicaly loaded) and does not depend on both the dll and exe begin compiled with the same compiler?
The layout I want from the dll's users pov is that they have an interface, and they can load a dll and call a factory method to get an instance of something implementing that interface eg for a simple Sprite I may have:
The main graphics class will then have a CreateSprite method for creating instances that implement ISprite.
(I am aware of COM, but I dont want to tie my entire project to windows at such a level Id have to start from scratch if I ever wanted to go cross platform)
You can't. The problem even when just exposing interfaces is that they use a vtable which is generally located as a pointer within the first 4 or 8 bytes, depending on native pointer size, of the class in Microsoft Visual C++. However there is no guarantee that all other compilers will implement it the same way. Furthermore not all compilers will call methods the same way, that is __thiscall isn't well defined like __cdecl and __stdcall. Generally __thiscall on Microsoft Visual C++ passes the this pointer in the ECX registry which is x86 specific. Most compilers are able to compile code that works in the same way as COM does though so it would be VERY advisable to make sure your classes are binary compatible with COM interfaces. COM is extremely simple once you start studying it, the most complex issues relate to multi threading and marshalling but I doubt you need to consider that for your simple system. The COM model can easily be translated to the other major platforms and you can easily write something which will work in a similar manner to COM yet cross compiles.
Author
Ok so how do I go about writing something that works like COM and is cross platform?
Quote:Original post by Fire Lancer
Ok so how do I go about writing something that works like COM and is cross platform?
SOAP or CORBA. Alternatively, Java or Python, C# might work too. Or plain old C with lots of #ifdefs.
Author
Quote:
SOAP or CORBA.
SOAP looks like its just a data protocall?
I'll check out COBRA as that looks intresting.
Quote:
Alternatively, Java or Python, C# might work too. Or plain old C with lots of #ifdefs.
How are any of them going to make my existing c++ code work in dlls in a compiler independent manner without using anything OS specific (ie COM)?
I achieved something like this by using
and including the header for the interface in the project using it
(and linking explicitly using LoadLibrary, GetProcAddress et al. )
But you'll need to have some sort of way of managing the memory being passed
between address spaces - I use another dll to do *ALL* the memory allocation
for all of my other dlls and my main executable.
extern "C" { Interface* GetClass();}and including the header for the interface in the project using it
(and linking explicitly using LoadLibrary, GetProcAddress et al. )
But you'll need to have some sort of way of managing the memory being passed
between address spaces - I use another dll to do *ALL* the memory allocation
for all of my other dlls and my main executable.
Author
The only works if there all built with the same compiler, if the dll and exe are built with differnt compilers it crashes when I try to use the class with an acess violation error. I'm pretty sure its because of the fact virtual methods are handled diffrently by diffrent compilers.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
