BTW: Other extremly simple DB (well, sort of) which could be used in D "as is" is described in my article on CodeProject http://www.codeproject.com/cpp/flattables.asp

Andrew.


"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4262F2C3.4050507@nospam.org...
> Thanks for the link. I'll read that as soon as I have time. Looks promising for quite a few projects of mine!
>
>
> Andrew Fedoniouk wrote:
>> Sorry this is the URL http://www.garret.ru/~knizhnik/fastdb.html

That was my first thought also. However...

Technically it's possible to have a stream which knows how long it is, but is not seekable.
Practically I'm struggling to think of an example.

On Sun, 17 Apr 2005 21:22:25 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
> Size() implies seekability.
>
> Someone using size() on non-seekable streams is making a programmer error, IMHO. My suggestion is a non-quenchable error.
>
>
> Ben Hinkle wrote:
>> What should size() of a non-seekable stream return or do? Currently it depends on the stream type: for a general stream it throws a SeekException and for a File on Windows it returns 0 (which is just what GetFileSize returns for non-seekable streams like pipes). I'm tempted to have it return ulong.max. Any objections?
>>  While I'm at it I'm making eof testing more efficient for both seekable and non-seekable streams by using the convention that if readBlock returns 0 then the stream is at eof (and I'd like to document that). Technically that wasn't part of the existing readBlock's documentation but it's what happens in practice and it comes in handy with non-seekable streams.

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.
If the stream does not know and/or cannot get a correct size it should throw an exception (or return a value meaning "indeterminate")

By "size" I am referring to the total number of bytes the stream will _ever_ contain, not "available" the number of bytes it _currently_ has available. (the two may be equal in some cases)

I'm not sure the exception should be a SeekException as technically I don't think being able to get a size has anything to do with seekability. Technically it's possible to have a stream which knows how long it is, but is not seekable. However, practically, I'm struggling to think of an example.

> Currently it
> depends on the stream type: for a general stream it throws a SeekException
> and for a File on Windows it returns 0 (which is just what GetFileSize
> returns for non-seekable streams like pipes).

For things like pipes, unless they've closed (and you've buffered the data from them) you wont really know the "size".

> I'm tempted to have it return
> ulong.max. Any objections?

Which would mean the size is what? What if someone assumes the size is correct and allocates that many bytes to read into? I reckon you need to return a value which means "indeterminate". i.e. -1 or something.

> While I'm at it I'm making eof testing more efficient for both seekable and
> non-seekable streams by using the convention that if readBlock returns 0
> then the stream is at eof (and I'd like to document that). Technically that
> wasn't part of the existing readBlock's documentation but it's what happens
> in practice and it comes in handy with non-seekable streams.

So "eof" will call readBlock? Or when readBlock returns 0 you'll set a flag which "eof" will check?

Regan

> Practically I'm struggling to think of an example.

HTTP GET stream. Client may know resource length upfront
(HEAD request) but such stream is not seakable. It is just socket stream.
But in any case that resource length is not the knowledge HTTP GET
shall rely on.

On Sun, 17 Apr 2005 18:59:08 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> Practically I'm struggling to think of an example.
>
> HTTP GET stream. Client may know resource length upfront
> (HEAD request) but such stream is not seakable.

You mean defined in the Content-Length header?
Or are we talking HTTP 1.1 which sends lengths then data? (IIRC)

Either way, if you instantiate the GET stream _after_ reading the length then I guess it could know it's length... if you instantiate before reading the length then there is a period where it has an indeterminate length.

Right?

> It is just socket stream.

So it doesn't know the length itself.

> But in any case that resource length is not the knowledge HTTP GET
> shall rely on.

Because the socket could close prematurely. You can only really know the length of a socket once it closes (once you know where it ends)

Regan

In article <d3v49f$2s9p$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>> Practically I'm struggling to think of an example.
>
>HTTP GET stream. Client may know resource length upfront
>(HEAD request) but such stream is not seakable. It is just socket stream.
>But in any case that resource length is not the knowledge HTTP GET
>shall rely on.

I haven't thought about the details but I could imagine a compressed stream like ZipStream that knows its length but isn't seekable.

In article <4262A961.9040102@nospam.org>, Georg Wrede says...
>
>Size() implies seekability.
>
>Someone using size() on non-seekable streams is making a programmer error, IMHO. My suggestion is a non-quenchable error.

Sounds reasonable - except I'll leave the non-quenchable part up to the application :-P. The default size() will throw a SeekException if the stream is not seekable. Subclasses can override size() is they want to do something else. That is more backwards-compatible anyway since the only non-SeekException-throwing streams were pipes on Windows.

>
> 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. :)

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.

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.

Andrew.

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!

Think of the OSI model, and keep the stream implementation focused.

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