Ada95 Streams Question

[Chris.Morgan@BAESEMA.CO.UK]

I have a question about Ada95 stream implementations. I mentioned this work a
little while back in response to a request for Ada95 success stories, but now
I'm feeling a little unsettled by accusations of being a hacker!

I'm principally aiming this at comp.lang.ada but cc:ing to report@gnat.com in
case someone there who's given up on the newsgroup cares to comment.

Background
==========

I have connected an Ada95 executable to a C++ executable using streams. The Ada
is the brains of the application, and the C++ is the Motif pretty face. On both
sides I have defined a set of portable types which application types are
converted to for transmission and converted from on receipt.

On the C++ side I have specialised the iostream operators in our C++ GUI
library for each low-level type (e.g. 1,2 and 4-byte signed integers, 4-byte
float, 8-byte float and so on) so that binary reads are performed, not ASCII.
This is simply a case of casting the object to a char* of the correct size
before doing the read or write (>> or <<).

On the Ada side I have declared types that correspond to these low-level types,
deriving portable integer types from Interfaces.Integer_n and unsigned integers
from Interfaces.Unsigned_n types. The only special thing I have done is the C++
library stil expects a linefeed after each object (it normally reads files) so
I add that on after calling the 'write attribute for each object
(character'write(ASCII.LF)).

This is all working fine and I get good performance with a named pipe created
in /tmp which is a form of shared memory. In fact I have quite a nice scheme
going where I have defined a root tagged type which defines the header for any
message to the C++, and then any real message is derived from the root. To
write any particular derived type is simply matter of calling
type'write(object) and away it goes. The only bit not tested yet is floats
which aren't very important in this app.

Question
========

How likely is it that the GNAT (or some other Ada95 compiler) implementation of
Ada stream_io would arbitrarily break this arrangement in future? I am told
that the in-stream representation is only recommended to conform to the
in-memory, but what are the actual chances of some implementation not following
this advice?

Am I really relying entirely on a pure coincidence that the C++ and the Ada95
definitions can work together, or is it in fact the only sensible scheme?

Some of my more senior colleagues think that Ada95 stream_io is broken for
Ada/C++ interworking, but the fact that it works exactly as I expected in my
setup is either a) pure coincidence or b) the result of Ada streams (at least
with GNAT) being implemented precisely to allow this. I know which I suspect!

Of course I am talking about the simple case where no tags are written (I'm not
using any dispatching) and no doping information, so I am suggesting that two
objects which are bitwise compatible in memory can naturally be passed forward
and back down streams between Ada95 and C++ and I can't see why this should
ever break.

(Note : I'm using GNAT3.05 on Sun-SPARC-Solaris2.5. Previous versions of GNAT
had a stream_io bug which held me up but which is now fixed. The C++ compiler
is the SunSoft SPARCCompilerC++ from SunSoft Visual Workshop for C++. Naturally
if the GUI worked with g++ I would have tried direct interworking.)

Thoughts?

Chris

--
--chris.morgan@baesema.co.uk
--Team Ada