Re: CRC in Ada?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Tom Moran says

<<Wow, I'm sure glad I didn't know when I started trying Ada that you
couldn't read a sequential file of fixed length records with the thing
called "Sequential_IO"!  I would have dropped it and stayed with
something reasonable, like C.   @.@>>

Well it's just possible that other people than Tom Moran have manbaged
to misread what i read :-)

so here is a further explanation.

Of course you can use Ada to read and write a file that is logically
organized as a sequential file of records, and that is exactly what
Sequential_IO does.

HOWEVER, the level of abstraction in C is quite different from that in 
Ada. In C, you know how the IO operations you write are reflected at the
fundamental level of the sequential butes of a file (of course this
low level understanding breaks down badly when you have more sophisticated
file systems like that on the IBM mainframes or VMS, but C folks generally
don't like such systems anyway ("if I can't read it with C, it must be broke")
so that doesn't matter to most C programmers.

The Sequential_IO, Text_IO and Direct_IO packages of Ada are at a significantly
higher semantic level. You have NO guarantees, none at all, of how the logical
structures they implement map down to the file level. You do have a guarantee
that the same code will operate in the same abstract manner regardlless of
the structure of the underlying file system, and, unlike the C programmer
who sits scratching their head wondering how C stream IO maps into BSAM
or ISAM file structures, the Ada programmer knows that their program will
run fine, no matter what the underlying file system looks like.

This has good points and bad points. The good point is this independence
from the underlying file structure, the bad point is this independence from
the underlying file structure!

If the problem is that you want to read existing data encoded in a certain
way (in the case under discussion a stream of bytes represented in a single
stream file), then there is no correct Ada solution using these high level
packages. Yes, you may be able to get something working by depending on
non-guaranteed implementation behavior of your current compiler, but you
are then writing implementation dependent code. 

As to how portable this code really is, who knows? Certainly the Ada
reference manual gives no hint, but sometimes, as many C programmers
know, you can write non-standard code that is in fact quite portable.
Maybe this code is in this category, maybe it is not, who knows. I know
of at least one counterexample where it would not work.

Note that Stream_IO in Ada 95 is not "just another IO package", it is
COMPLETELY different in style, in that, like the C streams package, it
is very low level, and the mapping to the external file is defined.
Stream_IO has the advantage that you really know what the mapping is,
and can base portable code on this knowlegde. Stream_IO has the disadvantage
that it has this low level mapping, and, for examle, I have no guess as
to what Stream_IO would do on top of a BDAM file on a 360 mainframe!

As for the "if I had known that Ada could not do X, I would have switched
to C", either this is entirely non-serious, or if serious, then it seems
odd to me. If you would switch to C on the basis of such a trivial excuse,
why bother to need an excuse at all, why not just use C in the first place?