From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2e11aa5522d5cc28
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Mixing Ada and C++. Is a good idea?
Date: 1997/11/12
Message-ID: <dewar.879347131@merv>#1/1
X-Deja-AN: 288947842
References: <345F7489.A10@si.ehu.es>
 <gwinn-1111972003010001@dh5055060.res.ray.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 879347508 3334 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-11-12T00:00:00+00:00
List-Id: <comp.lang.ada>


Joe says

<<Probably not.  Both Ada and C++ have very definite ideas about how their
runtime heaps should be organized, and it may prove difficult to keep them
from killing each other.  Nor will the debuggers work well, or at all.
The devil is in the details.

It may be better to have two worlds, one to a language, exchanging
messages (perhaps in shared memory).  Thus, each linked process image is
pure, being of one language or the other, and each is master of its own
private heap.

It's lots easier to mix ANSI C with Ada95 (not Ada83) than C++ with
anything, simply because C is much simpler than C++.  Is C++ really
necessary?  For that matter, is Ada really necessary?  Fewer languages
will be much simpler.

Greenhills has claimed for at least two years to be able to handle
mixed-language developments, with Ada95 and C/C++ in hybrid processes; it
works, but it isn't smooth.  Rational only recently began to claim full
support for mixed-language processes.  I don't have any experience with
GNAT Ada95 with Gnu C and I have heard no claims either way.>>


Robert replies

This is a highly implementation dependent issue. GNAT alone among current
Ada 95 compilers goes to a great deal of effort to allow the possibility
of direct interface to C++. In particular, GNAT allows for specifying the
format used for tagged types using a runtime library procedure. This
procedure can be specialized so that the format used for GNAT tagged
types is *absolutely identical* to the format used for classes in C++.

If this specialization is done, theb (classes/tagged types) are fully
interfacable, for example, a C class can be imported into Ada, primitive
opertoins (methods) added to extend the type on the Ada side, and the
extended type used directly in the original C code.

So far we have demonsrated interopability at this level using g++ and using
Delta C++ on SGI Irix. The latter capability is a key part of the technology
made available in the GNAT-based Ada product from SGI, which includes bindings
to their C++ graphics libraries that make use of this interfacing capability.

As for problems with organization of "run-time heaps", I don't see any
problems here, at least not for a compiler like GNAT, which rigorously
adheres to the ABI for the target machine.

Robert Dewar
Ada Core Technologies