[phobos] Removing std.stdio.File.popen()

[Andrei Alexandrescu]

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