[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: If you like "u8vector" ...
On 15-May-05, at 9:15 AM, Michael Sperber wrote:
... it'd be really nice if you could respond to:
"Moiself" == Michael Sperber
Moiself> I haven't done anything yet wrt. the naming issue---that's
Moiself> pending. I'd like to hold a little poll. For that, it'd be
Moiself> if the camp in favor of "u8vector" could suggest names for
Moiself> currently READ-BYTE, READ-BYTES, and READ-BYTES-N in SRFI 68.
First let me say that I dislike the read-bytes/read-bytes-n API
proposed in SRFI 68. Programmers expect binary I/O to be fast, but
that API requires the allocation of a new byte vector on each call, and
this will have a negative impact on the throughput that is achievable.
A better API is to have the client code (user program) allocate a byte
vector buffer, and have procedures that read octets into this buffer at
a specific position. For example:
(read-subu8vector! buffer start end)
This procedure would read octets into the u8vector "buffer" starting at
index "start" and ending at index "end", and return the number of
octets read or end-of-file (or #f) when at end-of-file. A similar
read-substring! would exist for reading blocks of characters into a
string. Note that this API also supports I/O on non-blocking ports (it
would be possible for the result to be less than "end - start"
anywhere, not just when limited by the end-of-file).
As for read-bytes/read-bytes-n, if you keep that API, the names
read-u8vector and read-u8vector-limited sound fine to me. The
procedure read-byte would be read-u8. Future extensions of SRFI 68
could provide read-u16, read-u16-be, read-f64, etc. as suggested by