On 2011-09-06 12:50, Steven Schveighoffer wrote:
On Sun, 04 Sep 2011 07:07:05 -0400, Jacob Carlborg <[email protected]> wrote:
On 2011-09-03 21:54, Andrei Alexandrescu wrote:
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio which would
obviate the need for etc.stream and would improve both the generality
and efficiency of std.stdio.
Please chime in with feedback; he's away from the Usenet but allowed me
to post this on his behalf. I uploaded the docs to
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Thanks,
Andrei
I think that openFile, File.open and CStream.open should shouldn't
take a string as the mode, it should be an enum or similar. Andrei is
making a big deal out of using enums instead of bools. A bool value
can contain "true" or "false", a string can contain an infinite number
of different values.
openFile takes it as a template argument, and it will fail at compile
time if the parameter is not correct (if not now, it will when the
library is ready for inclusion).
If it validates the string at compile time than that's great.
I agree that enum is cleaner and easier to deal with from the library's
point of view, but we have 2 things going for us by using strings:
1. The string formats are backwards compatible, and well defined. In
fact, CStream.open just passes the mode string without modification to
fopen.
2. The brevity of and ability to comprehend a string literal vs.
multiple enums.
You can think of it like printf (or writef). The format string has
infinitely wrong possible format strings, which must be rejected at run
time. But I'll take that any day over C++'s format modifiers which are
type checked at compile-time.
It's not very often I use the print format functions. Most of the time I
use Tango and with Tango's format strings at least you don't have to
specify the type.
Remember, typically, string formats are most frequently literals, and
easy to read/write. While there is great potential for invalid
parameters, the reality is this rarely happens, and if it does, the
errors are seen immediately.
-Steve
I would not say that they are easy to read, or at least
understand/remember what a given mode means. I always have to double
check the documentation when using these kind of modes. I always have to
check if a given mode creates a new file or not.
--
/Jacob Carlborg
