On 10/13/10 13:45 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 07:49 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
Agreed. Maybe this is a good time to sart making a requirements list
for streams. What are the essential features/feature groups?

Andrei

Maybe something like the following (I hope it's not too extensive):

* Input- Output- and InputAndOutput- Streams
- having InputStream and OutputStream as an interface like in the old
design may be a good idea
- implementing the standard operations that are mostly independent from
the data source/sink
like read/write for basic types, strings, ... in mixin templates is
probably elegant to create
streams that are both Input and Output (one mixin that implements most
of InputStream and
one that implements most of OutputStream)

So far so good. I will point out, however, that the classic read/write
routines are not all that good. For example if you want to implement a
line-buffered stream on top of a block-buffered stream you'll be
forced to write inefficient code.

So what's a possible alternative to the classic read/write routines?

It's something that ten people implement in eleven ways. Some starters:

1. Get one byte at a time. This may be inefficient.

2. Define this:

size_t append(ref ubyte[] buffer);

Such an interface allows the stream to append data to a user-maintained buffer. Then the user manages terminators etc.

3. Define this:

size_t getDelim(ref ubyte[] buffer, in ubyte[] terminator);

No. I just wanted to point out that it must be possible (and should be
easy) to wrap streams.

And efficient too! That means no buffering friction :o).

Agreed. Question: is there a file system that offers resettable but
not seekable files? I'm thinking of collapsing the two together.

As mentioned before in other branches of this thread: Probably no file
system, but maybe archive files (zip, ...)

I wonder to what extent resetting is really closing and reopening the file/connection.


Andrei

Reply via email to