extern "C" and wrapping

[bob]

Hi,

we're faced with a horrible scenario whereby we are not able to access
exported classes in a DLL due to cross compiler issues.

Traditional approaches such as using extern "C" and LoadLibrary
(nothing to do with C++ I know but I'll get to my question... .
Anyways, we need to access our exported objects and the only safe
route I know to get to the destination dll/lib from our client (not in
same environment) is by using extern "C" for various functions.

However doing this I lose all my object orientation. Is there any
pattern/approach out there available that will allow me to use extern
"C" such that its implementation gives me access to the C++ objects
implemented in the target DLL/LIB. I think this must be an age old
problem I'm just stumped by it and I honestly think somebody has a
clever pattern/approach to this that will allow me to bypass the
problem at hand.

I obviously can't replace all my objects method calls into extern "C"
functions and in paralell this must scale. I.E as new functions/
classes are added , I need to be able to access them without too much
pain, extra work.

Does anybody know of such a solution? Or is this unsolveable...i.e.
I'm asking too much.

thanks for any assistance.

GrahamO

 

[James Kanze]

we're faced with a horrible scenario whereby we are not able to access
exported classes in a DLL due to cross compiler issues.

Traditional approaches such as using extern "C" and LoadLibrary
(nothing to do with C++ I know but I'll get to my question... .
Anyways, we need to access our exported objects and the only safe
route I know to get to the destination dll/lib from our client (not in
same environment) is by using extern "C" for various functions.

However doing this I lose all my object orientation. Is there any
pattern/approach out there available that will allow me to use extern
"C" such that its implementation gives me access to the C++ objects
implemented in the target DLL/LIB. I think this must be an age old
problem I'm just stumped by it and I honestly think somebody has a
clever pattern/approach to this that will allow me to bypass the
problem at hand.

I obviously can't replace all my objects method calls into extern "C"
functions and in paralell this must scale. I.E as new functions/
classes are added , I need to be able to access them without too much
pain, extra work.

Does anybody know of such a solution? Or is this unsolveable...i.e.
I'm asking too much.

The way I usually handle plugins and such is to declare a
single, extern "C" function which returns a pointer to the
abstract base of a factory class; I then call member functions
on the factory class to get the objects I want (or do anything
else in the plugin, for that matter).

 

[Roland Pibinger]

The way I usually handle plugins and such is to declare a
single, extern "C" function which returns a pointer to the
abstract base of a factory class; I then call member functions
on the factory class to get the objects I want (or do anything
else in the plugin, for that matter).

"cross compiler issues" probably means that he wants to combine C++
code compiled by two compilers which use different name mangling. I
guess he is doomed.

 

[bob]

Hi Roland, and thanks James for your reply.


Roland, do you mean the approach is "doomed" .... i.e. even if we pass
link and get and exe with some functions/classes available... we will
ultimately hit a large dirty wall? Or do you use 'doomed' in the sense
that we have no other choice but providing we can do the mapping,
we'll be ok?

I'd like to know if our approach is destined for failure or is it the
case that if we get the symbols mapped and linked we should be ok.

OK put it this way... has anybody else out there done this?

thanks much. We have a very importance decision to make in the next 4
hours!!

GrahamO

 

[James Kanze]

Hi Roland, and thanks James for your reply.

Roland, do you mean the approach is "doomed" .... i.e. even if we pass
link and get and exe with some functions/classes available... we will
ultimately hit a large dirty wall? Or do you use 'doomed' in the sense
that we have no other choice but providing we can do the mapping,
we'll be ok?

Doomed means that it won't work. The approach I suggested will
allow you to get around the mangling problem (since only
function names are mangled, and you only call functions through
pointers in the vtable). With the result that everything will
compile and link just fine, but may core dump on execution,
because different compilers lay out the vtable differently.

I'd like to know if our approach is destined for failure or is
it the case that if we get the symbols mapped and linked we
should be ok.

All C++ must be compiled by the same compiler.

About the only way to get around this is to define a very, very
narrow interface in C, using C style structs, or even better,
serialized data, which you marshall and unmarshall at both ends,
and then take whatever steps are necessary on your platform to
ensure that your dynamicly linked component is autonome. (I
think this is the default for Windows. It takes some explicit
precautions under Unix.)

OK put it this way... has anybody else out there done this?

Some applications do use plug-in's, yes.

thanks much. We have a very importance decision to make in the
next 4 hours!!

Make it flexible, so you can go back and fix it when it doesn't
work.

 

[Roland Pibinger]

OK put it this way... has anybody else out there done this?

You haven't yet explained what "cross compiler issues" you face. Is it
really a name-mangling problem? Unlikely on Windows. I can only guess
(and my guess may as well be wrong). If it's Windows specific try one
of the Windows programming newsgroups.

 

[bob]

thanks for all the replies.... the issue is precisely differences in
name mangling. Borland mangles differently from ms. We're hacking!


thanks for the previous replies. I know have to start looking at some
very serious intelligent and workable solutions. BOOM goes my
weekend!


thanks again for any replies.

cheers

G

 

[Default User]

Hi Roland, and thanks James for your reply.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.com/c++-faq-lite/how-to-post.html>

 

[Roland Pibinger]

the issue is precisely differences in
name mangling. Borland mangles differently from ms. We're hacking!

Some time ago I had a problem linking a VC++ DLL to BCB. I don't
remember the solution but it's documented somewhere in the BCB
documentation. The following links may also be helpful (further
details are clearly off topic in comp.lang.c++):

http://www.devarticles.com/c/a/Cplusplus/DLL-Conventions-Issues-and-Solutions-Part-I/
http://www.devarticles.com/c/a/Cplusplus/DLL-Conventions-Issues-and-Solutions-Part-II/

 

[JohnQ]

Hi,

we're faced with a horrible scenario whereby we are not able to access
exported classes in a DLL due to cross compiler issues.

Traditional approaches such as using extern "C" and LoadLibrary
(nothing to do with C++ I know but I'll get to my question... .
Anyways, we need to access our exported objects and the only safe
route I know to get to the destination dll/lib from our client (not in
same environment) is by using extern "C" for various functions.

However doing this I lose all my object orientation. Is there any
pattern/approach out there available that will allow me to use extern
"C" such that its implementation gives me access to the C++ objects
implemented in the target DLL/LIB. I think this must be an age old
problem I'm just stumped by it and I honestly think somebody has a
clever pattern/approach to this that will allow me to bypass the
problem at hand.

I obviously can't replace all my objects method calls into extern "C"
functions and in paralell this must scale. I.E as new functions/
classes are added , I need to be able to access them without too much
pain, extra work.

Does anybody know of such a solution? Or is this unsolveable...i.e.
I'm asking too much.

thanks for any assistance.

While dated, the following link may be helpful:

http://www.microsoft.com/msj/archive/S330.aspx

I'd like to imagine that the Borland and MS compilers are a bit more
compatible these days. Whether or not you can get interfaces (that is, Pure
ABC's-Plus) to work reliably across compilers (and who's to say that your
program won't be broken by a vendor change in the future after you've
deployed?), I don't know. There's an old article in MSJ though that had that
goal way back when. I don't remember to what degree they succeeded or what
the final caveats were. The gist is, though, to put "behind the DLL wall"
the C++-isms of the objects (interaces) you get from your extern "C" factory
functions.

(Aside: COM (Component Object Model) provides a Microsoft way of doing
interfaces across tools and programming languages. Not that I'm
recommending/un-recommending it though.)

John