On Tue, 06 Sep 2011 08:49:22 -0400, Jacob Carlborg <[email protected]> wrote:
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.
writef is the same, %s is equivalent to calling toString().
But the format specifiers for Tango are also strings, and not compile-time
verified.
My point was simply, using a string to indicate flags or formatting
instructions is pretty efficient, easy to write, and easy to read.
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.
Yeah, creating a new file is implied by a combination of modes.
The one that's confusing I think is that "a" is for append, but "+" kind
of tacks on appending to any other mode. It's not the most well-designed
spec for file opening. Add to that you have the "b" which is a noop on
most OSes.
There is the possibility that we could accept an alternative open mode
string, which we could design better. But we have to keep fopen's spec,
it's already used everywhere.
-Steve
