On 08/18/2010 03:10 AM, Lars Tandle Kyllingstad wrote:
On Tue, 2010-08-17 at 22:03 -0500, Andrei Alexandrescu wrote:
I understand that, and the motivation has been thoroughly explained in
the Unix lore. My question is, why define a separate type? Wouldn't
creating a file and calling setbuf(null, 0) suffice?
Well, for one thing, I didn't know about setbuf() until just now. :)
I still think I prefer the UnbufferedFile solution, though. setbuf()
should be called before anything is read or written to the stream. This
means it will be up to the user to do so, and this is easily forgotten.
Compare
auto f = UnbufferedFile("myfile.txt");
...
auto p = spawnProcess("myapp", f);
to
auto f = File("myfile.txt");
setbuf(f.getFP(), null); // DON'T FORGET THIS!
...
auto p = spawnProcess("myapp", f);
spawnProcess could call setbuf itself and fail if that doesn't go through.
An alternative solution is to have the user specify whether File should
be buffered or unbuffered upon construction. Then spawnProcess() can
check this and throw an exception if the File is buffered.
auto f = File("myfile.txt", Buffer.none);
...
auto p = spawnProcess("myapp", f); // succeeds
As said above, I think CRT's setvbuf fails if called twice.
You mentioned a few months ago that you were considering
replacing/complementing the stdioOpenmode string argument to File's
constructor with an enum. Perhaps buffered-ness could also be an option
here?
auto f = File("myfile.txt", Mode.append | Mode.noBuffer);
If needed, sure. Yet if buffering isn't needed the old-style modes put
in a string seem to be adequate and are documented everywhere.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
