Regan Heath wrote:
> On Mon, 18 Apr 2005 12:59:20 +0300, Georg Wrede <georg.wrede@nospam.org>  wrote:
> 
>> Regan Heath wrote:
>>
>>> On Sun, 17 Apr 2005 12:23:32 -0400, Ben Hinkle <ben.hinkle@gmail.com>   wrote:
>>>
>>>> What should size() of a non-seekable stream return or do?
>>>
>>>  If the stream knows (or can get) a correct size then it should return  it.
>>
>>
>> Isn't the whole concept of stream (as opposed to file) precisely the  idea that you should not rely on any "knowledge" of it -- beyond what  you've already got!
> 
> 
> In that case no stream should implement "size", but only "available".  Where "size" means maximum number of bytes in this 'thing' and "available"  means number of bytes in it _now_.
> 
>> Think of the OSI model, and keep the stream implementation focused.
> 
> 
> OSI?
> 
> Regan

http://www.webopedia.com/quick_ref/OSI_Layers.asp

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d3v9ps$31hn$1@digitaldaemon.com...
> >
>> I haven't thought about the details but I could imagine a compressed stream like ZipStream that knows its length but isn't seekable.
>
> quod erat demonstrandum. :)

au contraire, existence of one does doesn't imply non-existence of the
other. :-)
Actually now that I think about it some more a program that extracts records
from a Zip file most likely skips immediately the file position with the
file to extract and reads from there. I looked at std.zip and it only works
on data in memory but it essentially does that.

> I told you! seakable streams are nonsense.
> Even for "simple" cases like text files....
> Text streams in different encodings  by definition has no "postion"
> As stream output may depend on physical byte number ***and***
> previous state of the stream.

position is defined by byte position, not character position (unless the encoding is dchars).

> Just think about it. Have you ever use any stream with positioning in your practice? It is either pure stream (getNextChar) or sort of block-oriented access like fread/fwrite. But not their mix.

yes I've used positioning with MATLAB many times. Finding and reading chunks of a file without having to read from the start is handy.

Ben Hinkle wrote:
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d3v9ps$31hn$1@digitaldaemon.com...
> 
>>> I haven't thought about the details but I could imagine a
>>> compressed stream like ZipStream that knows its length but isn't
>>> seekable.
>> 
>> quod erat demonstrandum. :)
> 
> 
> au contraire, existence of one does doesn't imply non-existence of
> the other. :-) Actually now that I think about it some more a program
> that extracts records from a Zip file most likely skips immediately
> the file position with the file to extract and reads from there. I
> looked at std.zip and it only works on data in memory but it
> essentially does that.
> 
> 
>> I told you! seakable streams are nonsense. Even for "simple" cases
>> like text files.... Text streams in different encodings  by
>> definition has no "postion" As stream output may depend on physical
>> byte number ***and*** previous state of the stream.
> 
> 
> position is defined by byte position, not character position (unless
> the encoding is dchars).
> 
> 
>> Just think about it. Have you ever use any stream with positioning in your practice? It is either pure stream (getNextChar) or sort of
>>  block-oriented access like fread/fwrite. But not their mix.
> 
> 
> yes I've used positioning with MATLAB many times. Finding and reading
> chunks of a file without having to read from the start is handy.

Files (ex. on disk) can be opened for serial access, or random access.

You can also read some, and then skip a number of bytes -- this can be
done both with files opened for serial or random access, and also with streams.

But positioning with a stream, that's not what a stream implementation should do. Neither trying to get the size.

The application _using_ your stream is of course free to pretend it can position. But that has to be done with opening your stream and just skipping (i.e. reading and discarding values) till the app is happy with the "position".

In general, streams should only do stuff that's "within the stream concept". For all we know, the stream could become connected to the keyboard, and then there is no way of knowing in advance how much or when Georg is going to type before he gets fed-up. Right?

----

It's like a programmer creates an array implementation. And while he's at it he writes the methods for FIFO, LIFO, Priority Queue, sorting, circular buffer, binary search, and whatever -- all directly in the array.

Wouldn't it be more practical to just have the basic operations of arrays in it, and then have other people implement the FIFO, etc. (Be it by inheritance or client classes or just procedural code that uses the array.)

A stream should do stream stuff only. (That's what I meant with the OSI model.)

>>> Just think about it. Have you ever use any stream with positioning in
>>> your practice? It is either pure stream (getNextChar) or sort of
>>>  block-oriented access like fread/fwrite. But not their mix.
>>
>>
>> yes I've used positioning with MATLAB many times. Finding and reading chunks of a file without having to read from the start is handy.
>
> Files (ex. on disk) can be opened for serial access, or random access.
>
> You can also read some, and then skip a number of bytes -- this can be done both with files opened for serial or random access, and also with streams.
>
> But positioning with a stream, that's not what a stream implementation should do. Neither trying to get the size.

I can see how the word "stream" could implies a bunch of data flowing by (or being generated) like water. But unfortunately that's that accepted term that is now used to include files and pipes and sockets etc. Since files (and memory streams) can be random-access and can have a size it is more practical to allow some form of "seekable streams" rather than create a different class and API just for random-access files.

> The application _using_ your stream is of course free to pretend it can position. But that has to be done with opening your stream and just skipping (i.e. reading and discarding values) till the app is happy with the "position".

That depends on the stream. Also what you describe would only allow the position to be set to something further along the stream instead of anywhere in the stream.

> In general, streams should only do stuff that's "within the stream concept". For all we know, the stream could become connected to the keyboard, and then there is no way of knowing in advance how much or when Georg is going to type before he gets fed-up. Right?

It is funny that after all these years of having computers around we humans still haven't figured out how to best deal with files and pipes and sockets. You'd think that API would have settled down in the 70's.

> Isn't the whole concept of stream (as opposed to file) precisely the idea that you should not rely on any "knowledge" of it -- beyond what you've already got!

I agree with Georg. on 100%.

And one more.

Stream is stream. Vector is vector.
You can build stream on top of vector
but not vice versa.

This is why for the sake of logical
simplicity/clearness they should not be combined
in one entitity.

Andrew.