Re: Mixing Ada and C++. Is a good idea?

[gwinn@res.ray.com (Joe Gwinn)]

In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza
<jipdisaa@si.ehu.es> wrote:

> Hello
> 
>         First: Sorry because my English is very poor!! I am learning so be
> patient please ;). Second: the problem. I wish make a program mixing C++
> libraries and Ada packages. The mixture will be total: the C++ side will
> call some Ada functions and the Ada side will call some C++ methods.  
> Is this a good idea? 

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.


> Can I share data structures between the two sides?

Yes, but be *very* careful with data structures that are seen by both
languages.  Each language can generate data structures that cannot be
directly expressed in the other. 

For data structures and/or messages that cross the border from Ada to C,
in either direction, it is necessary to nail each and every bit down, so
messages and/or data structures can be converted by a simple unchecked
conversion involving the casting (unchecked conversion) of a pointer
only.  So, the Ada (and C) must be *very* simple in this border region. 
Even if the communications is Ada to Ada, if different linked images are
communicating (via messages or shared data structures), it's necessary
that nothing be left to the compiler's imagination.   This is especially
necessary if the communication code resides on different processors (such
as 68040, 68060, PowerPC for today).


Tick size beartrap:  Where an Ada-coded module passes a buffer (specified
by its address and size) to a C-coded module, and the C module causes data
to be either read from or written to that user-supplied buffer, there is a
potential beartrap.  In Ada, all sizes are given in bits; while, in C, all
sizes are in bytes.  The classic bug is to forget, and ask the C to read
data into a buffer sized in bits, which the C interprets as the length in
bytes, returning eight times as much data as expected, clobbering all
manner of unrelated but nearby data structures.  It can take weeks to
track the cause down.  The hell of it is that the read itself works just
fine, and something with no obvious connection to the read dies, sometime
later, and for no obvious reason.  In many realtime operating systems, the
victim may be a different task than the culprit.  All in all, a Very Bad
Scene.  A good policy is to use sizes in bits (not bytes) in the Ada
world, and convert to bytes in the interface rroutines, so that mistakes
will cause too little data to be transferred, a simpler and more localized
bug to find and fix.



>         Another factor is that I am using object-oriented programming in two
> sides. 

Beware variant records in OO.  Ada83 variant records have the well-known
property that if anything in any record in the variant set changes,
everybody who uses any member of that set must recompile.  In practice, in
a project of any size, this means one recompiles the world just about
every day.  

Variant records were an issue in the Ada95 language design deliberations. 
The issue was that variant records in effect inherit upwards, the exact
opposite of what's required both for object-oriented code and for the
decsription of messages as specializations of a universal message type. 
Because a major requirement for Ada95 was support of object-oriented
designs, Ada95 changed how variant records work, so we may have a
Ada83-Ada95 portability issue here.  I don't recall if variant records
themselves were changed, or a new variant of variant records was added.  


> Must I import and export all methods, or can I export all then
> class from one side to another?.

I'm not quite sure I understand the question, but I will say that the Ada
methods will generally work only with Ada datastructures, and C++ methods
only with C++ data structures.  One could probably get cross access to
work, but it would be difficult and the result fragile.

As I said above, it's best to keep the Ada-C++ interface painfully simple,
and to keep the two worlds separated, with clean interfaces.


Good luck.

Joe Gwinn