Re: Building portable data structure (NOT a newbie question?)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <afniiik9q3c42e.fsf@Elysium.i-have-a-misconfigured-system-so-shoot-me> afniii@hades.arl.psu.edu writes:

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

  Not forbidden, but very compiler specific.  However, I think that
GNAT is headed in the direction you want.  (Canonical stream
representation for scalar types independent of hardware.)

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

  You can clean it up a lot in Ada 95...  Redefine the operations in a
package, and make everything child units of this package.  Now the
predefined types don't keep popping back up.  Works well when you are
creating a subsystem, where you want this structure anyway.

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

  No really easy solution.  Best is if someone provides a version of
GNAT (and you can be that someone) that uses a canonical
representation and bit order for all scalars.  Then your high-level
code just works with standard streams.  Or you could implement some
other canonical format, such as XDR.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...