Re: ADA/C++ Compatibility problems

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++;
I'm not suprised. Both have similar styles.
For example, both allow one to mix integers and defeat
the object-oriented style by accident.
Object-Oriented paradigm's should follow something such as
name equivalence, and never be mislead by structural equivalence.


>however, we've had some problems
>trying to mix ADA and C++, the problem is as follows:
Perhaps you mean "Ada" and "C++"? The Defense Department uses "Ada",
not "ADA". Please get the name of the language right.
It is Ada, as in "Ada95, the first Internationally Standardized
Object-Oriented Language". Follow the links from


<A HREF="http://www.acm.org/sigada/">
  ACMSIGAda -- A World-Wide Group associated with the
Association for Computing Machinery --
Computing's First Professional Organization</A>


    or from


<A HREF="http://lglwww.epfl.ch/Ada/">
        Ada Programming Language</A>




> A test program was written to test the ability to have an ADA main
>calling a C function which is an interface to a C++ method. The test took
>place on an HP 9000s700 series workstation, running the HP-UX verion 9.0.1
>UNIX operating system. The HP was using the following compilers: (1) HP
>C++ compiler version 3.05, (2) HP C compiler version 9.34 and (3) Verdix
>ADA (VADS) version 6.2.1k.
The question you should be asking is:
      Am I using Compilers that are *designed* for multi-lingual interfaces,
or am I using lowest-common-denominator style of interfaces? If so,
then it won't work. To understand what multilingual interfaces need,
I suggest reading abou the Multics run-time and how its descriptors
work so that calls from PL/I to FORTRAN (or similar cross-language
calls) are easy. If you want to know how the hard way, I suggest
reading the IBM OS/360 manuals that indicate the kind of interface
routine one needs to build to do cross-language calls from one language
to another when they don't support the same run-time paridigm.
[The last time I studied the unix run-time paridigm, it was too
simple to support multiple languages. K&R worked on the Multics
project, so they knew how to do it. It's just when they built
Unix, they chose [my understanding of their work] to use a unilingual
convention because their hardware, unlike the GE 645/..., didn't
suport "good parameter passing conventions" efficiently, and they
felt they could not afford to do generally in software.]


> A simple C++ class was created which contained a single variable and
>constructor to initialize it. A C++ function then instantiated an object
>of that class type, hence initializing it via the constructor. The C++
>function returned the value of the single variable. This function was com-
>piled and archived in a separate library. An ADA function was then written
>which called the C function via a PRAGMA command and also returned a the
>variable. This was compiled and stored in the ada.lib ada library. Finally,
>an ADA main was created which called the ADA function. The ADA main was
>then compiled and linked.
I believe you can do similiar actions with Ada95 and initializations
and finializations, and in a more efficent way. Try reading the
Ada95 rationale document (available without cost from the Ada Information
Clearinghouse). It documents what choices the Ada95 designers made,
from what alternatives they made their choices, and what were the
wins and loses from amking the choices. I've never seen such a book
for any other language. Might it be that most languages cannot justify
the choices they made? Can you refer me to a document that indicates
why what went into C++ went into C++? And not a C++ only document,
please. Let it discuss smalltalk and Ada95 and other object-oriented
languages strengths and weanesses as well.




> 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.
What is the one you think has malfunctions?
Which one do you believe has the invalid runtime?
Or is none of their runtime enough for all languages?


> We are currently searching for ways to resolve this ADA to C++ compa-
>tibility problem, because the driving forces at this lab mandate full
>support for older ADA legacy code. We would appreciate any ideas or resol-
>utions anyone may have to resolve this situation. Thanks..
Don't you mean "Support for older legagy C code?" From the way you
pose your question, it appears that you are unaware of Ada95,
and the ways in which its objects can be both efficient and safe.


What I use when I have to interface with "ugh" legacy systems
written in C and working with horrible OS'es that don't understand
concurrency (Are you really intending to write new code in this
area and ignore the wins you get from tasks? C++ doesn't begin
to understand concurrency issues) I use the GNAT compiler that
handles both Ada95 and C to write the code.


    Try following this URL:


<A HREF="ftp://cs.nyu.edu/pub/gnat/README">
        What is GNAT (Gnu NYU Ada Translator)?</A>


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.


My suspicion is that the G++ and GNAT efforts will eventually
merge; then you might have what you want, though probably not
what you need. I'm big on correctness and reliablity; in my
personal opinion, the driving out of better systems-implementation
language compilers (like PL/S, which had atomic updates of integer
variables in the language in 1972) by the low-cost, low-function
competitor set computing as a discipline back at least 10 years.


>[I fear you'll have to develop separate band-aids for each platform on which
>you plan to run this code. -John]
John: I don't think so. GNAT is based on GNU, which is highly portable.
The last time I read the documentation, it was on 17 platforms.
And I know that there are more since I counted in April.
I'm running Ada95 on both MS-DOS and SunSolaris 5.3/5.4 now, and will be up
with real multitasking at home once I get OS/2 installed on my home machine.


Paul D. Stachour, Software Engineer and Methodologist
9532 First Avenue South 260-6A-08 3M Center
Bloomington, Minnesota 55420 St. Paul, Minnesota 55144
(612)-884-5977 stachour@winternet.com (612)-733-5217 pdstachour@mmm.com
[Stroustrup recently published a book on the history and design of C++.
There's a whole bunch of books from the PARC crowd on the design of ADA, all
now out of print. And I promise this will be the last message ever on
comp.compilers that argues about how a language's name is capitalized. Sheesh.
-John]
--

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