C versus C++ compiler interoperability
by Thygrrr · in Technical Issues · 05/25/2002 (11:26 am) · 6 replies
Hello!
I'm /very/ much into OOP, which is why it has always been an eyesore that at the moment, our entire project is C++ modules interlocking and interacting via plain C interfaces, modelled in ways to somehow resemble 'interface objects'.
Anyway, what I'd like to know is whether there is a way to have C++ modules interact properly with each other (i.e. passing along classes, deriving classes of each other's abstract classes, etc) - while those modules are compiled and linked using /different/ platforms. This is considerably trivial, but a little unpretty in C, but I really doubt a GCC compiled C++ dll can every properly invoke the methods of the Borland C++ or MSVC++ - compiled other classes in their respective modules. I see problems arising especially when using virtual methods and such....
Does anyone have experience with this topic? The last thing I knew was that even minor version steps in the same compiler suite could render formerly compiled code unusable for newly built modules... but now I hear id revanmped their Doom III engine to be fully C++ - which I find apalling, because I have no idea how module interoperability and stability can be maintained, and how third party coders (read: mod-programmers) will be able to compile a C++ DLL containing the new game code.
I'm /very/ much into OOP, which is why it has always been an eyesore that at the moment, our entire project is C++ modules interlocking and interacting via plain C interfaces, modelled in ways to somehow resemble 'interface objects'.
Anyway, what I'd like to know is whether there is a way to have C++ modules interact properly with each other (i.e. passing along classes, deriving classes of each other's abstract classes, etc) - while those modules are compiled and linked using /different/ platforms. This is considerably trivial, but a little unpretty in C, but I really doubt a GCC compiled C++ dll can every properly invoke the methods of the Borland C++ or MSVC++ - compiled other classes in their respective modules. I see problems arising especially when using virtual methods and such....
Does anyone have experience with this topic? The last thing I knew was that even minor version steps in the same compiler suite could render formerly compiled code unusable for newly built modules... but now I hear id revanmped their Doom III engine to be fully C++ - which I find apalling, because I have no idea how module interoperability and stability can be maintained, and how third party coders (read: mod-programmers) will be able to compile a C++ DLL containing the new game code.
#2
The general answer is: no.
Name mangling techniques, core libraries, and some other stuff typically make this a maddening experience to try and work through. Unless you can force name mangling to 'visual c' or 'gcc' style always, and then you have a shot.
d
05/26/2002 (9:05 am)
I thought the question being asked was whether a C++ DLL from one compiler could easily interoperate with another.The general answer is: no.
Name mangling techniques, core libraries, and some other stuff typically make this a maddening experience to try and work through. Unless you can force name mangling to 'visual c' or 'gcc' style always, and then you have a shot.
d
#3
The problem is that ISO standard defines behavior, but not the actual means by which a compiler/linker achieves virtual method management.
05/26/2002 (9:40 am)
In fact, name mangling is nearly trivial if one uses explicit linking. The problem is that ISO standard defines behavior, but not the actual means by which a compiler/linker achieves virtual method management.
#4
You just have to specify the calling convention, like WINAPI* for DirectX functions:
Thereafter, you use fnDirectDrawCreateEx as a call to DirectDrawCreateEx.
If the function that you have linked to returns an instance of a class, then you can use it as if it were part of your module. Easy as that.
05/26/2002 (12:26 pm)
I use to use the cygwin compiler for all my C++ programs, and never ever ever had a problem linking to other DLL's compiled with other compilers. One example is DirectX. I dynamically linked to DX dll's without a hitch, and I'm sure it wern't compiled using cygwin.You just have to specify the calling convention, like WINAPI* for DirectX functions:
typedef HRESULT (WINAPI* FN_DirectDrawCreateEx)(GUID FAR *lpGUID, LPVOID *lplpDD, REFIID iid, IUnknown FAR *pUnkOuter);
HMODULE DirectDrawDLL = LoadLibrary("ddraw.dll");
FN_DirectDrawCreateEx fnDirectDrawCreateEx = (FN_DirectDrawCreateEx)GetProcAddress(DirectDrawDLL, "DirectDrawCreateEx");Thereafter, you use fnDirectDrawCreateEx as a call to DirectDrawCreateEx.
If the function that you have linked to returns an instance of a class, then you can use it as if it were part of your module. Easy as that.
#5
05/26/2002 (1:00 pm)
Interesting! But are you sure what you are calling is not just a C function (there is a big difference between calling extern "C" functions and using /classes/ and /virtual methods/ with their origins in other DLLs!)
#6
05/26/2002 (1:05 pm)
Oh, I didn't see that last conclusive statement under the code. That exactly is the question. I am very, very sure that one cannot use that clas. Can you show me some working code that does that? It's not about the principle, but it's about an example I can conduct my tests with. Several other users in other forums said as ISO doesn'T specify the way the VMTs are aligned in menmory, there is no way for your program to execute safely (and stable). 
William Finlayson
The one thing you have to watch out for is the calling conventions that your compiler uses. Make sure to use the same calling conventions in all your dll functions, and they will all work no matter what compiler was used. I can't remember what code is required to do that, but it's pretty simple.