Streaming transport interfaces: input

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Oct 14 10:39:03 PDT 2010


On 10/14/10 12:27 CDT, Steven Schveighoffer wrote:
> On Thu, 14 Oct 2010 11:34:12 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
> Please, use the term "seek", and allow an anchor. Every OS allows this,
> it makes no sense not to provide it.

I've always thought that's a crappy appendix. Every OS that ever allows 
seek/tell with anchors allows ALL anchors, and always allows either both 
or none of seek and tell. So I decided to cut through the crap and 
simplify. You want to seek 100 bytes from here, you write 
stream.position = stream.position + 100.

Oh, that reminds me I need to provide length as a property as well. This 
would save us crap like seek(0, SEEK_END); ftell() to figure out the 
length of a file.

I have no sympathy for seek and tell with anchors.

> I don't like appendDelim. We don't need to define that until we have
> buffering.

Why?

> The simple function of an input stream is to read data.

It does read data.

> With
> buffering you get all the goodies that you want, but the buffer should
> be in control of its data buffer.

I think the appendDelim method allows fast and simple implementations of 
a variety of patterns. As I (thought I) have shown elsethread, without 
appendDelim there's no way to efficiently implement a line-oriented 
stream on top of a block-oriented one.

> Basically, appendDelim can be defined outside this class, because the
> primitive read is enough.

You can only define it if you accept extra copying. I'd say one extra 
interface function is acceptable for fast I/O.

> Shouldn't the text transport be defined on top of the binary transport?

No, because there are transports that genuinely do not accept binary data.

> And in any case, I'd expect buffering to go between the two.

How do you define buffering? Would a buffered transport implement a 
different interface?

> If all you
> are adding are the different widths of characters, I don't think you
> need this extra layer. It's going to make the buffering layer more
> difficult to implement (now it must handle both a text version and
> abinary version).

I don't understand this.


Andrei


More information about the Digitalmars-d mailing list