On 10/14/10 12:27 CDT, Steven Schveighoffer wrote:
On Thu, 14 Oct 2010 11:34:12 -0400, Andrei Alexandrescu <seewebsiteforem...@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
