Re: ADA/C++ Compatibility problems

Paul D. Stachour (stachour@klondike.winternet.com) wrote:
: dasilvia@sonalysts.com (David Sivia) writes:


: >Ladies and gentlemen,


: > I work at the Naval Undersea Warfare Center in Newport, RI.. We are
: >currently working on a project, called PHOENIX, which is programmed in
: >X and C++ using an Object-Oriented paradigm.. Unfortunately, because we
: >are in the Defense industry, we must still be able to communicate with
: >legacy systems using ADA and C.. Therefore, we must give this legacy code
: >some type of interface to communicate with our newer systems using C++..
: >We've been successful mixing C and C++;


[... ...]


: GNAT as it is today (well, since about February, 1995, I think)
: mixes Ada95, Ada93, C89, and even some pre-standard 89 C quite well.


Convincing the NUWC to use a copylefted compiler might be a bit of a
challenge, (some managers are funny about that sort of thing) but
it will probably be worth it. As part of the GNAT distribution there
is a longish (30 page?) postscript file on how to mix C++ and Ada
class-type things. I remember printing it out, so it must be
somewhere in my filing cabinet...


Anyway, I only remember a few details, such as that it is quite
possible to cross-inherit (i.e. have a C++ class derived from an Ada95
class which is derived from a C++ class), and that there was something
funny with exception handling across the two. I must confess I only
glanced through this since I was just learning Ada at the time, and
the situation has never arisen since for me to need to have to do the
trick.


So to answer David's problem in short, there should be no problem in
doing what you want if you run with the GNU compilers. On the
downside, there are still a few problems with both GNAT and GCC - not
all of Ada95 is implemented (but pretty well all), and in C++ you
can't have optimisation and templates at the same time. This may mean
doing a little modification to your current code.










: > The ADA main executed properly as long as the C++ function and class
: >didn't contain certain C++ functions (i.e., streaming operators like cout
: >or cin). Whenever we tried using the streaming operators a run-time exep-
: >tion occurred. We tried explicitly calling the _main() C++ initialization
: >function in the ADA main, but also caused a run-time exeption.




Hmm, what platform are you running this on? I ask because this does
seem similar to a problem from elsewhere. Sun in their infinite
wisdom and helpfulness provide the SunOS 4.1 I/O libraries for the
Solaris Ada compiler. (They're pretty much compatible, and it
generally works, so I guess they couldn't be bothered getting the
last couple of percent fixed. This might have changed in more recent
SunAda compilers.) SunCC, on the other hand, uses the Solaris
libraries. It wouldn't suprise me terribly to discover that mixing
I/O from the two causes exceptions. (So to answer Paul, it's quite
possible that Ada could be causing the problem...) Solaris GNAT uses
effectively the same libraries as g++, so it should work fine.


But as far as I can imagine, there's no particular reason why in
general/in theory cout and cin should be affected by what other i/o
functions there are floating around. So if you can sort that one out,
you should be able to do everything you want.


(Here's an exceptionally ugly trick for linking totally unlikely
languages together under Unix. Suppose you wish to call function foo
(written in language 1) from function bar in language 2.
Change the name of foo to something like fooXQYZQXQYZ (something that
will really look unique in the object file). In language 2, call the
function fooZXASXAXAXAZ. This will fail to link, but will tell you
how language2 name mangles. Now grep foo's object file for
XQYZ... (and hope it didn't mangle too far). This will tell you how
language 1 mangles the name fooXQYZ. Write a perl/sed script that
replaces the latter with the former, and run it over the foo object
file. Hope like heck that parameter handling works as you expect.
(It probably doesn't, but you never know). Try linking again. Run
it. Spend the next week trying to explain to all and sundry what it
was you did. BTW The perl script probably won't need to be changed if
you make any changes and need to link again.)




Greg Baker (gbaker@rp.csiro.au) http://www.rp.csiro.au/~gbaker
CSIRO Radiophysics / Australia Telescope National Facility / AAO
--

Return to the comp.compilers page.
Search the comp.compilers archives again.