Piotr Dembinski wrote:
>
> Hi all,
>
> First of all, I apologize if the question I pose is silly, stupid or
> offtopic. I had read FAQ, HOWTO and this mailing list archive, but
> neither of them could fully solve my problem. So, I'm here and ask
> Gurus how to do this.
there are several issues involved:
1/ getting some functions addresses. this can be done using
LoadLibrary/GetProcAddress functions
2/ C++ name mangling; as you known, a C++ compiler uses internally
what's called mangled names, so that in can distinguish between methods
with same names, but in different classes, or overloaded methods (in the
same class). So from a class, method and arguments type list a mangled
name is created (for example, __5String6GetNthI could be
String::GetNth(int);) However, name mangling is compiler dependent. so
if your DLL exports mangled names, you have to take care of that
3/ the "glue" code is in fact always generated: under Windows, when a
program loads DLL D and uses some of its entry points, a Windows
compiler/linker does the following:
- from D, it creates a small (static) library which is linked/embedded
inside the program. This libs defines the entry point functions for D
so that program D can link (all symbols resolved). When the program is
loaded (or when a function for the DLL is called) the address for
the effective function (in D) is gotten by the program so that a call
to that address can be done.
you can imagine such a 'stub' as:
int the_function(type1 p1, type2 p2)
{
static int (*pf)(type1, type2);
if (!pf) pf = GetProcAddress(hlib, "the_function");
return (pf)(p1, p2);
}
the glue is only needed to make the bridge between two modules (program
and DLL) even if they are separate entities
in your case, when the DLL 'big function' returns a function pointer, it
can be called.
4/ when it returns an object, that's may be a bit more hard. As seen above,
C++ doesn't specify name mangling, you may run into trouble with:
- objects layout
- virtual methods
interoperability of c++modules compiled by different vendors is not given
(in your case a windows compiler vs gcc)
those are the main reasons why C++ interfaces to DLL are a bad idea
COM/DCOM tries to fill this gap (as CORBA does)
HTH
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
