User forums > General (but related to Code::Blocks)

CB dll project -> used in an M$ Visual project : troubles

<< < (2/3) > >>

killerbot:
In the code situation I am in now, I don't use an implib, I LoadLibrary and GetProcAddress. And I can call the exported functions. My trouble starts when the factory function (one of the exported functions) return a class object (well actually a pointer to a class object). Could it be, it's only c++ that gives troubles (every compiler probably does the name mangling different) ?

Tomorrow I am going to do one more experiment : I will translate my class to a simple struct and have all of it methods become a simple function, taking as a first argument a pointer to the struct (explicit this pointer mechanism). I hope this works ...

All other suggestions are off course welcome.

pjk:

--- Quote ---The exported functions seem to work well. One of those exported functions is a factory function which return a pointer to an class object created on the heap in the dll. When invoking member methods on that pointer, things go wrong.
--- End quote ---
The exported function is not name mangled but the member methods of an object certainly will be and Microsoft and GCC are certainly  incompatible at this level. I am not a compiler guru but I believe the term is Application Binary Interface It not only involves name mangling but other compiler specifics such as structure alignment on word boundaries etc. This may not even be compatible across different versions of GCC. The GCC site has some information and links to more.  http://gcc.gnu.org/onlinedocs/libstdc++/abi.html

pjk:
Sorry. I should add that there should little problem using DLL which export only C functions from one compiler to another. There is sometimes a problem with slight name modifications such as prepended underscores, but this is easily overcome with .def files.
The problem in killerbot example is that he has exported a C funcion but then used this function to export a pointer to a C++ object.
If you need to write your dll using C++, you can still make it usable by other compilers if you provide C functions which interface with the C++ objects such that the C++ objects are not seen outside the dll.
I not sure that this was expressed verywell despite english being my native language, but I hope you get my meaning.

The Unlord:
Hmm, I find all this quite hard to believe...  :shock:

How does, for instance, DirectX (or DirectShow) solve this (or other COM based API's).
What you do is call
CoCreateInstance(ClsID, blabla, &pObj);
which returns you a pointer to a COM object, on which you might for instance call
pObj->QueryInterface(blabla);
This, in the end is exactly the same, or am I missing smthg here?

This would mean that you can only develop DirectX apps with Visual Studio, or, more generally, COM apps with the compiler that generated the COM object you wish to use.
Hard to believe, but still...

pjk:
As I said I'm no guru and I know nothing of COM. I searched the mingw site for help and found the following from John Gaughan
--- Quote ---COM is, at its core, a way to implement certain object-oriented
 functionality in non-object-oriented code As such it is inherently
 C-based, although it does work fine with C++
--- End quote ---
http://sourceforge.net/mailarchive/message.php?msg_id=9076353This may explain how it is possible to interface with com.

Navigation

[0] Message Index

[#] Next page

[*] Previous page