Re: CRC in Ada?

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

In article <OHK.97Mar6080224@edeber.tfdt-o.nta.no>, ohk@edeber.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> In article <1997Mar5.131846.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

>    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 think you are missing something here. Altough in Unix it IS possible
> to do reads of arbitrary length, the standard IO library of C
> definitely does IO in blocks. The getc/putc functions are
> usually implemented as macros, which just manipulate the buffer. Of

And relying on performance characteristics of a particular implementation
which are not mandated from implementation to implementation brings
problems.  (Perhaps this implementation technique _is_ mandated,
but it is not something I would know.)

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

> It should be no harder to implement the putc/getc funtions on any
> other OS which allows you to do character IO in blocks, than it is in Unix.

And any vendor in the non-Unix space can choose to emulate as many
Unix characteristics as they choose, including performance-related
ones or not.

> It may be a mistake in some cases, but talking about "this mistake" is
> a vast oversimplification. Surely, there is nothing conceptually wrong
> with having a set of single character IO operations like putc, getc,
> and ungetc?

It is a mistake to assume performance semantics (if that is the term)
which are not present in the target environment.

Don't get me wrong, I think there are many instances for non-portable
code in the world. However just because something written in Ada (or
C) will compile and get the right answer in another environment, that
does not mean it is portable from the standpoint of the end user who
must wait for the results.

Larry Kilgallen