Specifying a buffer size to BufferedFile seems to make it fail to open the file. This looks really fishy because it doesn't look like the stream's fault:


import std.stream;
int main()
{
   BufferedFile f;
   f = new BufferedFile("test.d", 1000); // Error: Cannot open or create file 'test.d'
   return 0;
}


The file does exist, it's the name of the source file.


Documentation for readLine() says it fills a buffer or allocates a new one if it's not large enough, but it should say that it does this via appending, otherwise it will unsuspectingly step on adjacent memory. Something like that should be documented.


I said this before, but here it is again for the record, I think OutputStream.writef/writefln should return OutputStream and not Stream. Leaving it how it is now kind of defeats the purpose of separating Stream into OutputStream and InputStream.


Suggestion: class TextStream that reads strings instead of binary when using read(out int), for example. It could read values like scanf() would for the matching type. din/dout/derr would be good candidates for TextStream.

On Thu, 16 Jun 2005 05:29:38 -0400, Vathix wrote:

> Specifying a buffer size to BufferedFile seems to make it fail to open the file. This looks really fishy because it doesn't look like the stream's fault:
> 
> 
> import std.stream;
> int main()
> {
>     BufferedFile f;
>     f = new BufferedFile("test.d", 1000); // Error: Cannot open or create
> file 'test.d'
>     return 0;
> }
> 
> 
> The file does exist, it's the name of the source file.

Try this instead ...

  f = new BufferedFile("test.d", FileMode.In, 1000);

-- 
Derek Parnell
Melbourne, Australia
16/06/2005 10:35:52 PM

"Vathix" <vathix@dprogramming.com> wrote in message news:op.ssghzodqkcck4r@esi...
> Specifying a buffer size to BufferedFile seems to make it fail to open the file. This looks really fishy because it doesn't look like the stream's fault:
>
>
> import std.stream;
> int main()
> {
>    BufferedFile f;
>    f = new BufferedFile("test.d", 1000); // Error: Cannot open or create
> file 'test.d'
>    return 0;
> }
>
>
> The file does exist, it's the name of the source file.

I'll see if there's a way to cause this to fail to compile. I think it is converting the 1000 to the FileMode enum instead of considering it as the buffer size.

> Documentation for readLine() says it fills a buffer or allocates a new one if it's not large enough, but it should say that it does this via appending, otherwise it will unsuspectingly step on adjacent memory. Something like that should be documented.

Makes sense. I'll send Walter a modified doc page saying it appends to the
supplied buffer instead of saying it allocates a new one (or whatever it
currently says).
I'm curious, though, if this behavior caused a problem in your code since
it's possible the right thing to do is to change the behavior of readLine.

> I said this before, but here it is again for the record, I think OutputStream.writef/writefln should return OutputStream and not Stream. Leaving it how it is now kind of defeats the purpose of separating Stream into OutputStream and InputStream.

agreed.

> Suggestion: class TextStream that reads strings instead of binary when using read(out int), for example. It could read values like scanf() would for the matching type. din/dout/derr would be good candidates for TextStream.

I should hunt down whatever Sean was doing with readf/scanf. One issue with overriding read(out int) to parse text is that it would (IMHO) add more confusion to the issue about what is binary and what is text. Currently it is very simple that read/write is binary and writef/scanf/readLine/getc/etc is text. It would be nice, though, to make it easier to read numbers from a text stream. Maybe another function called something like scan(out int) would be for doing that.