• Vathix (24/24) Jun 16 2005 Specifying a buffer size to BufferedFile seems to make it fail to open t...
• Derek Parnell (7/23) Jun 16 2005 Try this instead ...
• Ben Hinkle (18/42) Jun 29 2005 I'll see if there's a way to cause this to fail to compile. I think it i...

Vathix <vathix dprogramming.com> writes:

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.

Derek Parnell <derek psych.ward> writes:

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

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"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.