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

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

[Arantza Diaz de Ilarraza]

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 a
good idea? Can I share data structures between then two sides?
	Another factor is that I am using object-oriented programation in two
sides. I must import and export all methods or can I export all then
class from one side to another?.

				Thank for the response.


Aitor Maritxalar
University of the Basque Country

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

[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

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

[Robert Dewar]

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

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

[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

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

[Robert Dewar]

Joe said

<<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.
>>

It begins to be clear that Joe is offering general advice across all
languages, rather than specific advice for Ada 95. In that context, his
otherwise surprising advice is not at all surprising, because it is
most certainly true that for other languages, his advice is appropriate.
I would guess that Joe has not used pragma Convention and the other
important features of Ada 95, and does not appreciate the extent to
which this problem has been successfully solved in Ada 95.

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

[Robert Dewar]

<<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.
>>

Debuggers are a poor substitute for knowing the languages that you work
with properly. Sure I can see how poorly trained programmers could be
confused about the semantics of sizeof and 'Size, but this is the kind
of error that good programmers avoid in the first place. How such an
error could take weeks to find is beyond me. But I guess people can be
arbitrarily non-productive when they get dragged into the debugger mire.

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

[Ed Falis]

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.

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


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.

>
>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.

>> 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 it 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.

>
>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.

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

>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.


>
>
>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.

>
>
>
>>         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.
>

Too much to get into here, but tagged types were the solution adopted.

>
>> 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, 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


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.

- Ed  Falis
Aonix

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

[Matthew Heaney]

In article <gwinn-1111972003010001@dh5055060.res.ray.com>,
gwinn@res.ray.com (Joe Gwinn) wrote:

>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.  

If you're recompiling the world every day, then something is wrong with the
design of the application, not with the language.

This phenomenon often occurs when a "common types" package is being used,
that contains a lot of low-cohesion type declarations that everyone with's. 
Add another type, and everyone who touches that package needs to be
recompiled.  You need to break the single, large, low-cohesion package up
into several smaller packages, that each contains a set a high-cohesion
types.  That way, when you add another type, only that corner of the
application that depends on that specific package needs to be recompiled.

If you're doing a message passaging (perhaps the common types package
declares a variant record containing all message types), then use the
streams facility, so a package only depends on the predefined streams
packages.  You might even consider deriving message types from a
Root_Message tagged type, so that message tags will be determined by the
compiler.  Better still is to use the distributed systems annex.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Joe Gwinn]

In article <mheaney-ya023680001511971659520001@news.ni.net>,
mheaney@ni.net (Matthew Heaney) wrote:

> In article <gwinn-1111972003010001@dh5055060.res.ray.com>,
> gwinn@res.ray.com (Joe Gwinn) wrote:
> 
> >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.  
> 
> If you're recompiling the world every day, then something is wrong with the
> design of the application, not with the language.
> 
> This phenomenon often occurs when a "common types" package is being used,
> that contains a lot of low-cohesion type declarations that everyone with's. 
> Add another type, and everyone who touches that package needs to be
> recompiled.  You need to break the single, large, low-cohesion package up
> into several smaller packages, that each contains a set a high-cohesion
> types.  That way, when you add another type, only that corner of the
> application that depends on that specific package needs to be recompiled.

It was a nice theory, one that we never did get to work in a project of
any size, because the inherent cohesiveness of the variables was not all
that high.  This has been true in all projects past some critical size,
regardless of language, from the days of assembly on to the present.  

Having never gotten such a thing to work in the past, in any language, I
have simply given up on the approach.  Another nice theory.


> If you're doing a message passaging (perhaps the common types package
> declares a variant record containing all message types), then use the
> streams facility, so a package only depends on the predefined streams
> packages.  You might even consider deriving message types from a
> Root_Message tagged type, so that message tags will be determined by the
> compiler.  Better still is to use the distributed systems annex.

Streams?  In Ada83?  I don't think so.  

In my current project, now in Ada95, we cannot use the streams because we
are using a COTS middleware package to implement damage-tolerant realtime
communications, and this middleware package has its own APIs.

Joe Gwinn

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

[Joe Gwinn]

In article <dewar.879560344@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> <<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.
> >>
> 
> Debuggers are a poor substitute for knowing the languages that you work
> with properly. Sure, I can see how poorly trained programmers could be
> confused about the semantics of sizeof and 'Size, but this is the kind
> of error that good programmers avoid in the first place. How such an
> error could take weeks to find is beyond me. But I guess people can be
> arbitrarily non-productive when they get dragged into the debugger mire.

Well, we don't usually compiler experts for plow-the-fields coding, and
it's an easy mistake to make, especially if one believes that Ada's error
checking will catch all such problems, especially in a large-scale
project.  No matter how careful we are, it always comes down to debugging
at midnight.  We wish it weren't so, but it is so, has always been so, and
probably will always be so.

My gripe is with programmers so ill trained that they cannot debug at the
assembly level, when necessary.  Nobody claimed it was pretty.

Joe Gwinn

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

[Robert Dewar]

Joe Gwinn says

<<That's what all language folk say, for all languages.

Details aside, simpler is usually better, for all languages.  I don't
doubt that some probelms have been solved, but the history of
inter-language bindings isn't exactly smooth.  Pardon me if I don't
believe that Ada95 is any different in this.

Joe Gwinn
>>


No, that's plain wrong. I can only guess it comes from a lack of familiarity
with Ada 95. In fact Ada 95 is quite different from other languages in this
respect, I have no idea what silly things people do or do not say about
languages, but Ada 95 is quite unique among standardized languages in 
paying considerable attention to providing high level language features
at an appropriate level of abstraction for interfacing to C, Fortran,
and COBOL in the standard.

I am almost certain that Joe is simply unfamiliar with these features, and
we can pardon him for not knowing Ada 95, but I don't think we can pardon
him for making plainly incorrect statements based on this ignorance :-)

For example, the declaration for a record type X

   pragma Convention (C, X);

that says "lay this record out exactly the way C would lay it out", has no
analog in any other standardized language (actually I don't know of *any*
language in which it has an anolog, but surely among the hundreds of
non-standard languages there must be similar examples).

Joe, I really think you should take the time to read chapter 13 and annex B
of the reference manual to see if your statement seems supportable *to you*
once you know the facts.

I am perfectly sympathetic to your experiences of difficulties in this area,
they are very common. I am even sympathetic to your induction that Ada must
be no different, but unfortunately, Ada is the exception that proves the
rule here (yes, yes, I know that is not what this phrase means :-)

Once on comp.lang.cobol, someone asked how to portably interface between
COBOL and C, and basically the answer, from many contributors, was that
there was no way.

I pointed out that there was a way, although a vey peculiar one. By writing
glue code in Ada 95, it is possible to write a tri-lingual program containing
Ada, COBOL, and C units, since the interface between Ada and COBOL is
well defined and the interface between Ada and C is well defined. For instance
here is the code to convert a recvord from the storage format used by C to
the storage format used by COBOL.

   type x is record ...
      ...
   end record;
  
   type y is new x;

   pragma Convention (C, X);
   pragma COnvention (COBOL, Y);

   VX : X;
   VY : Y;

   VX := X (VY); -- convert from COBOL format to C format

Robert Dewar
Ada Core Technologies

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

[Matthew Heaney]

In article <dewar.880118394@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Joe says
>
><<It was a nice theory, one that we never did get to work in a project of
>any size, because the inherent cohesiveness of the variables was not all
>that high.  This has been true in all projects past some critical size,
>regardless of language, from the days of assembly on to the present.
>
>Having never gotten such a thing to work in the past, in any language, I
>have simply given up on the approach.  Another nice theory.
>>>
>
>And yet, many programmers, who understand abstraction reasonably well,
>*have* got this approach to work fine, in very large projects.

I'm with Robert on this one, Joe.  If you understand abstraction, and if
you're _smart_ about how to use Ada packages to capture those abstractions,
then all is well.  Yes, you can have very real problems with Ada when
you're not smart about how you use packages, but this isn't a language
issue per se.  If that's your situation, get some help from an Ada
consultant.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

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

[Robert Dewar]

Joe says

<<It was a nice theory, one that we never did get to work in a project of
any size, because the inherent cohesiveness of the variables was not all
that high.  This has been true in all projects past some critical size,
regardless of language, from the days of assembly on to the present.

Having never gotten such a thing to work in the past, in any language, I
have simply given up on the approach.  Another nice theory.
>>

And yet, many programmers, who understand abstraction reasonably well,
*have* got this approach to work fine, in very large projects.

Could your failure be related to the same factors that make you think
that all programming ultimately ends up in midnight debugging sessions?

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

[Larry Kilgallen]

In article <dewar.880074788@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> Joe Gwinn says
> 
> <<That's what all language folk say, for all languages.
> 
> Details aside, simpler is usually better, for all languages.  I don't
> doubt that some probelms have been solved, but the history of
> inter-language bindings isn't exactly smooth.  Pardon me if I don't
> believe that Ada95 is any different in this.
> 
> Joe Gwinn
>>>
> 
> 
> No, that's plain wrong. I can only guess it comes from a lack of familiarity
> with Ada 95. In fact Ada 95 is quite different from other languages in this
> respect, I have no idea what silly things people do or do not say about
> languages, but Ada 95 is quite unique among standardized languages in 
> paying considerable attention to providing high level language features
> at an appropriate level of abstraction for interfacing to C, Fortran,
> and COBOL in the standard.

Although that feature of Ada 95 may be helpful, it is a shame it is
required, rather than having compilers for all languages interface
with each other automatically on a given platform.  That does require
that devotees of all languages agree that there might be a place for
other languages in the world, and so far even Ada does not have that
attribute across all its fans.

Larry Kilgallen

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

[Robert Dewar]

Larry says

<<Although that feature of Ada 95 may be helpful, it is a shame it is
required, rather than having compilers for all languages interface
with each other automatically on a given platform.  That does require
that devotees of all languages agree that there might be a place for
other languages in the world, and so far even Ada does not have that
attribute across all its fans.
>>

First, one cannot speak for "Ada and all its fans" at any time. Given the
many ludicrous postings to CLA, one could never expect the supposed fans
of Ada to agree unanimously on anything sensible :-)

However, it clearly is the case that Ada 95 very much takes the position
that other languages have an important place. A great deal of effort went
into refining the already superior features of Ada 83 in this area. At
no time did any of those involved give any other signal than that this was
an extremely important part of the language.

So I think you can definitely say that Ada 95 and its knowledgable advocates
absolutely agree that there are places for other languages, most notably in
regard to reuse of existing libraries.

As to Larry's "shame it is required", you cannot possibly expect "automatic"
interface. In fact it is this completely ill-thought out wish that leads to
some of the weaknesses in the Ada 83 model. These are weaknesses of 
under-specification *at the language level*. The thought in Ada 83 was that
if you provide pragma Import (C, xxx), then procedure xxx will indeed
automatically interface with C on that platform.

But that is sloppy thinking. The trouble is that the parameter passing
model is different at the semantic level between C and Ada. This means
that a correspondence has to be established which involves choices that
show up at a high level of abstraction in the user code, and cannot be
buried in the code generation.

As an example, if we have a C formal parameter that is of a struct type (NOT
a pointer to struct), then how should it be modeled on the Ada side. There
are two possibilities:

As a record type
As a pointer to record type

Ada 83 had nothing to say in this area, Ada 95 chooses the pointer approach
(though this particular case is a tricky one, and the ARA agreed on the
additional pragma C_Pass_By_Copy to resolve the trickiness. The fact that
the ARA considers the specification of the mapping in this case to be of
sufficient importance to warrant inter-vendor agreement on an appropriate
pragma to resolve a remaining insufficiently specified point should of itself
be an indication of the importance attached to this issue).

Actually this seems to be the only case not 100% handled in C, Fortran,
and COBOL interface protocols in Ada 95 (and with the new pragma, which
is implemented by all Ada 95 vendors, or should be!, that little hole is
plugged).

Now C++ and Java interface issues are not yet resolved (a reflection of the
fact that C++ was not standardized, and Java did not exist, at the time of
the Ada 95 design completion), but work proceeds on to work out the best
possible common interface for Ada 95 (e.g. at Tri-Ada, Intermetrics and
Ada Core Technologies agreed to work together on trying to achieve maximum
practical commonality in interface to Java).

There simply is no such focussed concern on this issue when it comes to
other languages. If you want to level a charge against fans of a language
of ignoring other languages, that charge lies much more accurately when
applied to other languages than Ada 95!

Robert Dewar
Ada Core Technologies

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

[Anonymous]

On 20 Nov 1997 20:22:02 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

> 
> Joe Gwinn says
> 
> <<That's what all language folk say, for all languages.
> 
> Details aside, simpler is usually better, for all languages.  I don't
> doubt that some probelms have been solved, but the history of
> inter-language bindings isn't exactly smooth.  Pardon me if I don't
> believe that Ada95 is any different in this.
> 
> Joe Gwinn
> >>
> 
> 
> No, that's plain wrong. 

Sorry, Robert, but we can't call another's beliefs "wrong." Joe can
believe whatever he wants, no matter how contrary to fact it may be.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Son of a window-dresser."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/