Re: CRC in Ada?

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <E6Kxux.FL9@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1997Mar5.083233.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>For Ada, I would guess that implementors have not counted on
>>people using C-like programming constructs (vs. doing large
>>buffer reads as suggested earlier in this thread).
>>
>>It is certainly possible to build an Ada environment optimized for
>>single-character reads, but that would not seem to be a priority
>>for most Ada compiler customers.
> 
> I think I disagree.  Buffering should be the job of the OS and/or
> standard libraries.  Not every program.

While theoretical computing and Alan Turing may be centered on
the equivalence and correctness of programs, in the real world
performance is also a consideration.  Just as those using intense
computation will be concerned about the efficiency of their
algorithms, those accessing large databases will take care
regarding order-of-access so as not to go skipping over the
whole thing when some locality-of-reference would yield better
performance.  Those reading sequentially from disk should
likewise concern themselves with performance, and 512 calls
to even the lightest-weight library is too much if a single
call would do.  For the stated problem (CRC) reading large
blocks is a clear win.

> I'm not sure why reading a file character-by-character is "C-like".
> It seems like the natural way to write lots of programs, in any
> language.  The underlying language and OS should ensure that it can be
> done efficiently (by making the "give-me-a-char" routine read from a
> buffer whenever appropriate).

In my experience it is generally C programmers who make this mistake.
Perhaps it because many of them come from a Unix background where there
is no strong sense of a "record".  On the other hand, it may just be
that there are so many C programmers that statistically speaking most
of the mistakes made will be made by a C programmer.

Larry Kilgallen