Re: CRC in Ada?

[jsa@alexandria (Jon S Anthony)]

In article <5g4k31$g54$1@A-abe.resnet.ucsb.edu> Graham Hughes <graham.hughes@resnet.ucsb.edu> writes:

> Now, any stdio library can do this any way it damn well pleases, but the
> *usual* way to implement the buffers is this:
> 
> If you request a character to be read, it feeds you the next character
> in the buffer.  If there isn't a next character in the buffer, it reads
> in BUFSIZ elements and tries again.  If it can't read any elements in,
> then it returns EOF.
...
> Now, since BUFSIZ is 1024 bytes on my computer, this is in fact quite
> efficient.  The actual BUFSIZ varies from compiler to compiler and
> platform to platform, much as stdio itself does.
> 
> I don't see why this is so hard to do in Ada.  It's the most used
> library in C (even hello world programs call printf()).

It's not.  It's easy.  But you might not get that from the way this
thread has progressed.  As Robert pointed out back at the start (and a
couple of times since), use Read and Write directly on buffers of
stream elements _instead_ of the attributes String'Read and
String'Write.  The latter require character by character processing
(per RM element by element processing of arrays in streams).

OK, so clearly the Read/Write for streams into buffers will be very
efficient and you can then chop this at your leisure.  But there are a
still a few issues in all this.

First, for GNAT String'Read/Write should boil down to a getc/putc or
some such C read/write, so any extra overhead here (beyond what you
have in C) should not be due to any buffering aspects whatsover.  They
will be due to call overhead on the C IO function.  The claim that
started this twist in the thread here, was that this overhead made the
IO "very slow".  I guess the problem is with "very".  3 times slower?
4 times?  What?  And are these examples of "very slow"?  Perhaps.
Regular ol' getchar, of course, can avoid this call overhead - though
I suppose it may not: thread safety issues anyone?

Second, while 13.13.2(9) sez that for composites (including arrays)
the associated Read and Write attributes call the Read/Write
attributes for each _component_, I don't see why this can't be one of
those cases where "as if semantics" apply.  For example, for one
dimensional arrays, just read the thing as if you called Read/Write
for each element.

Third, since you can specify stream oriented attributes ('Read 'Write)
for any type with an attribute definition clause, you can always just
change the "efficiency" behavior of String'Read/Write to be just like
getchar's by inlining a version which does what getchar does.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com