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

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

In article <EJnFDo.68y@sd.aonix.com>, "Ed Falis" <falis@ma.aonix.com> wrote:

> I don't know what deployment environment we're talking about here, but I
> think Mr. Gwinn's interpretation of the situation is way out on the overly
> negative end of the spectrum.

Some call it experience.  I have worked in many environments and
languages, some better than others, and have over the years become
enamoured of simplicity.

 
> Since what I'm most familiar with is the win32 environment, I'll offer some
> counter-interpretations from that context.

OK.  A datapoint.


> Joe Gwinn wrote in message ...
> >In article <345F7489.A10@si.ehu.es>, Arantza Diaz de Ilarraza
> ><jipdisaa@si.ehu.es> wrote:
> 
> >>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.
> 
> For the win32 world (at least with our compiler, ObjectAda), we use the
> standard operating system services of the win32 api to allocate memory.
> There is no conflict, provided that the Ada and C++ sides don't decide to
> explicitly deallocate each other's dynamically created objects.
> 
> The MsDev debugger works just fine with mixed Ada, C++, assembly etc,
> because they all use the same debug symbol format.  This is not to say that
> it supports special capabilities for threads (though a cross version
> integrated with Phar Lap ETS does), or that it necessarily represents array
> indexes the way an Ada programmer expects, but it remains usable and a good
> complement to the Ada debugger, which will only see the C++ code at the
> assembly level.
> 
> >
> >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.
> 
> In my opinion, it depends on the situation and on whether the functionality
> is naturally better supported by something as heavy as an additional process
> with DLL or shared memory
> based communication.

No performance and/or realtime issues were raised by the questioner, who
appeared to be more concerned with getting the code written and working,
so it isn't obvious that an added process is too heavy in this case.  My
advice was therefore directed towards designing as much complexity as
possible out, right from the start.


> >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.
> 
> In general, I agree:  it's easier to mix Ada 95 with anything than Ada 83;
> it's easier to mix ANSI C with anything than C++.  But the main problem area
> is sharing dispatching types across the language boundaries, which is
> probably not the best design approach to take, unless you want to step up to
> CORBA.

As I said elsewhere, it's not really a good idea to attempt cross dispatch
of methods, unless you wish to learn a great great deal about how both
languages and langauge runtime systems work.  This may not be what the
questioner came for.

Almost anything would be less painful than CORBA.

 
> >> 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.
> 
> Ada 95 helps substantially in this regard relative to Ada 83, by providing
> standard package Interfaces.C and its child units.  This leads to good
> uniformity with the basic C/C++ types, so that record representations
> corresponding to structs and so on can be laid out fairly easily.

Sounds like a good idea to me, if it's comprehensive enough.


> >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.
> 
> This strikes me as the court of last resort, when better techniques like
> using the standard definitions in the Interfaces packages are available.
> 
> >So, the Ada (and C) must be *very* simple in this border region.

See above.  I guess my experience over many languages is that interfaces
between languages are best kept simple because the programming models of
those languages are always somewhat or even radically different. 
Something always manages to bite you.

 
> Then how do you explain the successful use of large bindings like win32ada?

I don't think the questioner has available the resources that were applied
to produce the win32ada binding, so the existence of such a binding gives
no information on how difficult an individual or small team will find it
to bind unrelated languages, especially ones as complex as Ada95 and C++.

 
> >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).
> 
> Sure, but this is not a language-mixing issue per se.

True enough, but a common enough problem to be worth the warning the
questioner was clearly asking for, and not something would guess from the
language manuals.


> >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.
> 
> No argument here.

Yes, and that too is well worth the warning.  When I said you could waste
project weeks on this, I wasn't talking about something I read about
somewhere.  The root cause was only discovered by assembly-level debugging
of generated code after the development team had stalled, their fancy
source-level debuggers having proved useless.


> >>         Another factor is that I am using object-oriented programming on
> >> both 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.
> >
> 
> Too much to get into here, but tagged types were the solution adopted.

OK.  I do recall that.  I did see people get terribly tangled up with
varient records, so it was worth a warning, especially in view of the
expressed desire to use OO.


> >> Must I import and export all methods, or can I export all then
> >> class from one side to another?.
> 
> Currently GNAT supports inheritance across language boundaries, but it's
> (almost necessarily) messy.  (We don't yet).  So, for the gnat compiler, you
> could presumable import on a class basis; for our compiler on a
> method-by-method and data definition basis.
>  
> >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.
> 
> There are an awful lot of existing bindings that provide counter-arguments
> to this statement, where data types associated with the binding are
> manipulated extensively on both sides of the binding.  I will agree, though,
> when looking at dispatching types with compiler-specific hidden components,
> that there are complications that are better avoided.

As I said above, unless one can make use of an existing binding, typically
produced at great expense in blood and treasure, it's best to keep the two
worlds apart to the extent possible within the needs of the project at
hand.  Why bite such a thing off if you don't have to?


> >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.
> 
> I think the "painfully simple" part is overstated, but agree heartily with
> the old high-cohesion, low-coupling philosophy.  It's just not really a
> cross-language issue per se.

The questione has some problem he wants to solve using Ada and C++, but he
does not appear to wish to become a languages guru.  Thus, the advice to
keep it simple, unless there is a compelling reason to do otherwise.  He
appears to be more interested in the house than the hammer and saw used to
build the house.


Joe Gwinn