-**** Posted from RemarQ, http://www.remarq.com/?a ****-
Search and Read Usenet Discussions in your Browser - FREE -
As far as I know, only GNAT implements a direct interface
between Ada and C++ code. In any case, this is likely to be
quite compiler dependent. If you are indeed using GNAT, then
you should contact rep...@gnat.com with your customer number
and we will be happy to help.
Robert Dewar
Ada Core Technologies
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Few if any Ada compilers understand the mangling gyrations of the typical
C++ compiler. Hence you need to use extern "C". You don't need
to modify the existing C++ code to do this. You could write an
interfacing layer in C++ that uses extern "C" for what it exports to Ada
(or C), and contains calls to the existing C++ routines of interest.
Also, if there is no overloading in the C++ header file, you
can rename the existing C++ header, create a new one with the
old name, consisting simply of:
extern "C" {
#include "renamed_header.h"
}
> ...
> Thanks!
> Chris
--
-Tucker Taft s...@averstar.com http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA
It is not possible to link C++ to other languages without using extern C
in a portable way. There is no standard mangeling scheme, and it may
vary from compiler to compiler, even on the same OS. Extern C in C++
is in many ways similar to pragma import/export in Ada, since both
specifies a different linker convention from the default for the language.
Using 'extern C' is not a workaround, but the intended solution.
--
Gisle Sælensminde ( gi...@ii.uib.no )
No, that's not quite right, there *was* no "intended solution".
Why not? Because at the time Ada 95 designed there was not
officially standardized C++ language, so the Ada 95 standard
could not address this particular issue.
It is perfectly possible for an Ada 95 compiler to have built
in knowlegde of such things as C++ mangling (after all it has
to have detailed knowledge of how the Fortran, C, and COBOL
compilers on a given target handle data).
Also, using the extern C approach is quite limited, it does
not for instance come close to allowing C classes to be passed
transparently and treated as Ada 95 tagged types on the Ada
side, something that the GNAT interface makes possible.
Our approach in GNAT in providing a direct interface to C++ is
to use the same data structures for tagged types as C++ uses
for classes (the run-time library must be specialized to match
a particular compiler). As far as name mangling goes, we leave
that up to the binding generator tool, which knows the mangling
scheme. In the absence of this tool, you have to figure out the
mangling yourself (not impossible at all to do from the nm
output).
As I have noted before, ACT has long term plans to make this
binding generator available, but we do not have any release
data for this product (it is the binding generator that was
used to generate all the SGI C++ bindings that come with the
SGI Ada 95 product).
I did not think about the Ada95 design, but that of C++. It is
specified in the C++ standard that there is a C++ linkage convention,
which differs from the C convention, so 'extern C' is neccesary
to make C linkage, and not a workaround.
Fine, but this is comp.lang.ada, not comp.lang.c, so we are
interested in interfacing from C++ to Ada (C is not in
necessarily in sight unless we drag it in).
And the answer is no, it is not necessary to use extern C in
interfacing between Ada 95 and C++ if your implementation (like
GNAT) supports interfacing directly to C++.
See the example of this interfacing that comes with the GNAT
distribution.