Building portable data structure (NOT a newbie question?)

[afniii@hades.arl.psu.edu]

From the title this sounds like a newbie question, but I don't think
it is. Just for background I have 5 or so years of experience with Ada
and the last year plus with Ada 95. To build structures which are 
portable between platforms has always required this nasty package in
Ada 83 in which all of the predefined types get redefined and constrained
to some specific value. An endian changer was need after that along
with a float representation converter. Well I'm back at it again with
Ada 95. I really dislike the Ada 83 method and I think it would be
even more difficult to do with the tagged types and classes.

The problem:

There are a pile load of classes and records which are shared among
machines. They are recorded to a movable medium (such as disk) and 
moved to the other machine for access in some cases. In others they
are sent via a TCP/IP socket. In all cases the machine distribion is
heterogenous (sorry, but this is the part that makes it a challenge).
So I need a way to convert the lowest primitives (ie: discrete types
and floating point types) into a platform indepenent form. Still need
to minimize memory and disk allocation (cpu resources are cheap and
abundant) so converting everything to a string is out (but has been
considered).

Oh yeah. I almost forgot. No CORBA, IDL's or such either. I can't
afford them and I want the compiler to catch most of my errors for
me. If I didn't want that, I would program in C. :)


Options:

Convert all discrete values to a fixed endian (big or little endian)
before sending or recording. This is actually what I would like to
have done using streams (see attempts below).

Note however that GNAT does not yet support the 'BIT_ORDER attribute
except for the System.Default_Bit_Order. This would have worked out
well for the discrete value case. If you are reading this Robert Dewar,
any comment on when that 'BIT_ORDER attribute may be ready?

For floats I was considering converting everything to IEEE float.
Then I read up on all of the new floating point attributes and 
decided that there must be a better way. I could use the exponent and
fraction attributes and do something. Well that fizzled pretty quick.


By now you should get the idea of what I am trying to do. If not let
me know and I will elaborate some more.


Attempts:

To let you know what roads I have already walked:

Using streams seems to be the solution. Maybe this is a red herring and
that is why I have not found a good solution yet, but I think not. 
Unfortunately, I can find no way to override the predefined types 'READ
'WRITE, "INPUT, and 'OUTPUT attributes. This would really solve it. Of
course I could write one of those hated units with new definitions of
integer, natural, float, etc in them, but I hated that in Ada 83 so I am
sure I will hate it in Ada 95. Once you make on of those things you have
to always be dragging it around with a with clause then a use clause for
the operators and stuff. Heck, if I want to do that I would with and use
the predefined unit.

So after much horsing around, I found that using streams was really easy
and things worked well. Except the files and such were not portable --
obviously. That is when I tried the 'BIT_ORDER attribute with no success.

Then I realized that the output from the streams units may not, and in
fact are not, be protable because the type element defined in streams is 
platform or implementation independent. But, if I can get everything 
uniform in a stream, I can convert the stream to a fixed stream 
(ie: a byte stream where the element is always defined as mod 8). 
Then I would need to write a simple convert utility on each platform to 
go back and forth and IT would be solved.

So after much more horsing around, I became a believer of the Ada 95 LRM
and that I could not redefine the 'READ etc attributes for the predefined
type without first deriving a new type from them. I don't like that
solution at all.


So whose got a better idea?
I would like the output to be at stream from the Ada package streams.




(The return address on this post is probably wrong. Please use the
email address given below if you feel you want to respond that way)


Al Niessner III
email: afniii@hades.arl.psu.edu