On Wed, 30 Jun 2010 13:13:33 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Walter Bright wrote:
Adam Ruppe wrote:
My network thing is very simple: it opens a socket, then wraps it up
in a File struct, via FILE*. Then, you can treat it the same way.
That's the traditional way to do it, but I'm not so sure it's the
right way for the future. Wouldn't it be better to have an interface to
it that is a range, rather than pretend it's a FILE* ?
I initially also thought that a file (or socket etc.) should be a range,
but then I realized that that would overload roles. It's best to have a
handle/ranges architecture in which the handle (e.g. File) is
responsible for opening, closing, and managing the connection, and
several ranges are responsible for fetching data in various ways (by
character, by chunk, by line etc.)
BTW I'm virtually done implemented readf. I only need to parse
floating-point numbers and strtod won't work. Walter, could you please
email me your strtod implementation? Thanks.
The current issue with readf (and other similar formatted read routines)
is that they require a primitive peek() that looks up the current
character in a stream without swallowing it. This is not a FILE*
primitive, but can be simulated (slow) by using getc() and ungetc().
Fortunately on GNU's I/O libs peek() is easy to define (actually they
have an internal routine by that name), and on Windows dmd uses Walter's
I/O library, which again has fast peek().
I really think D needs to replace FILE * with it's own buffering scheme.
That way we can control the underlying buffering and have access to it.
We can also take advantage of D features that aren't available in the
underlying code, such as thread local storage to avoid taking global locks.
-Steve
