I'm curious, how much D code is there that mixes FILE* from std.c.stdio and
File objects from std.stream?
Do people mix them alot? Is it by accident or on purpose? For what purpose?

In article <d74k3o$2gco$1@digitaldaemon.com>, Ben Hinkle says...
>
>I'm curious, how much D code is there that mixes FILE* from std.c.stdio and
>File objects from std.stream?
>Do people mix them alot? Is it by accident or on purpose? For what purpose?

None here.  But perhaps it would be worthwhile to rename D stdin and stdout for clarity anyway.  din and dout follows the C++ convention, though I can't say I much like it.  Any other suggestions?


Sean

Sean Kelly wrote:

> None here.  But perhaps it would be worthwhile to rename D stdin and stdout for
> clarity anyway.  din and dout follows the C++ convention, though I can't say I
> much like it.  Any other suggestions?

I have my "douts" about those names, I must say. :-P

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d74svg$2ng2$2@digitaldaemon.com...
> Sean Kelly wrote:
>
>> None here.  But perhaps it would be worthwhile to rename D stdin and
>> stdout for
>> clarity anyway.  din and dout follows the C++ convention, though I can't
>> say I
>> much like it.  Any other suggestions?
>
> I have my "douts" about those names, I must say. :-P
>
> --anders

yeah, that is kindof clunky. But I don't think a rename is enough. There's
something bigger that should be discussed - or at least I hope Walter will
think about. My own worry is that D has two "standard" io mechanisms. Say
someone is writing a book introducing D (hypothetical, I know!). The first
program is presumably something like
  import std.stdio;
  int main(char[][] args) {
    writefln("hello world");
    return 0;
  }
or, if printf is still in object.d and the author prefer's C it will be
  int main() {
    printf("hello world\n");
    return 0;
  }
I hope, though, that the author is trying to teach the reader good habits
and will use writefln instead. My question is what is next program that
writes hello world to a file? I'm guessing it will be
  import std.stdio;
  int main(char[][] args) {
    FILE* f = fopen("out.txt","w");
    fwritefln(f,"hello world");
    fclose(f);
    return 0;
  }
The alternative today would be
  import std.stream;
  int main(char[][] args) {
    File f = new File("out.txt",FileMode.OutNew);
    f.writefln("hello world");
    f.close();
    return 0;
  }
The two versions have advantages and disadvantages - but the author has to
choose one or the other. And if they choose to import different modules to
direct io to a file as opposed to the console then that needs explanation.
So if std.stdio talks about FILE* I'm tempted to say D's primary "stream" io
is FILE* and uses writef and fwrite/fread (a nice symmetry there, actually).
It's possible we could remove std.stream.stdout etc and add a class that
wraps FILE* so that if a user really wanted a stream interface to stdio they
could make one using something like new CFile(stdout). Basically streams
would become a class interface to FILE* or wrapper around non-FILE* io.
Another way of phrasing the issue is to put oneself in the shoes of a
library writer who is writing a feature that takes a file input. How do they
declare their function? Does it take a FILE*, File or mango file class or a
callback like std.format or even something else? I think the D community
would benefit from some clarity on what D's io story is (which also gets to
clarity on phobos in general but that's a bigger question).

Mango.io takes care of all this, Ben <g>

All files, sockets, etc are all instances of Conduits. Once you have a conduit instance, you can read/write it directly, or you can wrap it with a Buffer. Buffers can be read/written directly, or they in turn can be wrapped with a variety of readers & writers.

Mango.io provides pre-built Stdin, Stderr, and Stdout reader/writer instances, which one can use in a variety of different ways:

#  Stdout << 10 << " green bottles";
#
#  Stdout (10) (" green bottles");
#
#  Stdout.print ("%d green bottles", 10);

Note that Stdout is nothing more than an instance of Writer ~ you can do the above with any type of Conduit endpoint, an array within memory, or a Memory-Mapped version of a file.

In addition, the classes representing files, paths, etc are fully cohesive ~ there's no overlap of functionality or confusion over what to use in any given context (as you note that there is within Phobos). It's all very simple.

Mango.io also supports the configuration of char/wchar/dchar encoders & decoders, directly within the I/O layer itself. It also supports the full range of native D types, plus the full range of native one-dimensional array types, along with the ability to bind one's own classes directly to the I/O system. In fact, the Mango version of printf supports all those native arrays too. Reader instances know how to deal with arrays correctly, and there are pluggable performance enhancements available to manage, or sidestep, related memory allocation. Combined with class serialization, it's a potent yet surprisingly simple package to use.

Mango has a bunch more besides:

- Wrappers around the unicode ICU project (with a very usable String module)
- A Log4D logging package, with hooks into Chainsaw plus a dynamic
application monitor/manager.
- Clustered caching and queuing
- High performance HTTP server, with Servlet engine
- HTTP client

Each of which use the mango.io package extensively.



"Ben Hinkle" <bhinkle@mathworks.com>...

> yeah, that is kindof clunky. But I don't think a rename is enough. There's
> something bigger that should be discussed - or at least I hope Walter will
> think about. My own worry is that D has two "standard" io mechanisms. Say
> someone is writing a book introducing D (hypothetical, I know!). The first
> program is presumably something like
>   import std.stdio;
>   int main(char[][] args) {
>     writefln("hello world");
>     return 0;
>   }
> or, if printf is still in object.d and the author prefer's C it will be
>   int main() {
>     printf("hello world\n");
>     return 0;
>   }
> I hope, though, that the author is trying to teach the reader good habits
> and will use writefln instead. My question is what is next program that
> writes hello world to a file? I'm guessing it will be
>   import std.stdio;
>   int main(char[][] args) {
>     FILE* f = fopen("out.txt","w");
>     fwritefln(f,"hello world");
>     fclose(f);
>     return 0;
>   }
> The alternative today would be
>   import std.stream;
>   int main(char[][] args) {
>     File f = new File("out.txt",FileMode.OutNew);
>     f.writefln("hello world");
>     f.close();
>     return 0;
>   }
> The two versions have advantages and disadvantages - but the author has to
> choose one or the other. And if they choose to import different modules to
> direct io to a file as opposed to the console then that needs explanation.
> So if std.stdio talks about FILE* I'm tempted to say D's primary "stream"
io
> is FILE* and uses writef and fwrite/fread (a nice symmetry there,
actually).
> It's possible we could remove std.stream.stdout etc and add a class that wraps FILE* so that if a user really wanted a stream interface to stdio
they
> could make one using something like new CFile(stdout). Basically streams would become a class interface to FILE* or wrapper around non-FILE* io. Another way of phrasing the issue is to put oneself in the shoes of a library writer who is writing a feature that takes a file input. How do
they
> declare their function? Does it take a FILE*, File or mango file class or
a
> callback like std.format or even something else? I think the D community would benefit from some clarity on what D's io story is (which also gets
to
> clarity on phobos in general but that's a bigger question).
>
>

Ben Hinkle escribió:
> Another way of phrasing the issue is to put oneself in the shoes of a library writer who is writing a feature that takes a file input. How do they declare their function? Does it take a FILE*, File or mango file class or a callback like std.format or even something else? I think the D community would benefit from some clarity on what D's io story is (which also gets to clarity on phobos in general but that's a bigger question). 
> 
> 

I'm part of the camp that thinks that std.c.stdio is C and not D, so when I do things like that I use std.stream. Weird thing is that I prefer writef() over stdout.writef() ... Hehe...

-- 
Carlos Santander Bernal

"Carlos Santander" <csantander619@gmail.com> wrote in message news:d75r8b$f4a$1@digitaldaemon.com...
> Ben Hinkle escribió:
>> Another way of phrasing the issue is to put oneself in the shoes of a library writer who is writing a feature that takes a file input. How do they declare their function? Does it take a FILE*, File or mango file class or a callback like std.format or even something else? I think the D community would benefit from some clarity on what D's io story is (which also gets to clarity on phobos in general but that's a bigger question).
>
> I'm part of the camp that thinks that std.c.stdio is C and not D, so when I do things like that I use std.stream. Weird thing is that I prefer writef() over stdout.writef() ... Hehe...

same here. Actually I typically use printf since it is in object.d so I don't have to import anything and it handles pointers better than writef (when I'm debugging and I have an object x and I want to print the address of x I can't use writef - very annoying).

On Thu, 26 May 2005 21:50:57 -0400, Ben Hinkle wrote:

[snip]
> ... Actually I typically use printf since it is in object.d so I don't have to import anything and it handles pointers better than writef (when I'm debugging and I have an object x and I want to print the address of x I can't use writef - very annoying).

  writefln("Address of object is %08X", &x);

-- 
Derek
Melbourne, Australia
27/05/2005 12:07:15 PM

Carlos Santander wrote:
> I'm part of the camp that thinks that std.c.stdio is C and not D, so when I do things like that I use std.stream. Weird thing is that I prefer writef() over stdout.writef() ... Hehe...

I admit to often being naughty and adding an "alias stdout.writef writef;" to the tops of my modules that use std.stream...  I'm probably just making a confusion trap for anyone else who reads that code, but it saves me ty ping "stdout" a thousand times in debug-console-logging code.

-- Chris Sauls

"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d75vht$hkv$2@digitaldaemon.com...
> Carlos Santander wrote:
> > I'm part of the camp that thinks that std.c.stdio is C and not D, so
> > when I do things like that I use std.stream. Weird thing is that I
> > prefer writef() over stdout.writef() ... Hehe...
>
> I admit to often being naughty and adding an "alias stdout.writef writef;" to the tops of my modules that use std.stream...  I'm probably just making a confusion trap for anyone else who reads that code, but it saves me ty ping "stdout" a thousand times in debug-console-logging code.
>
> -- Chris Sauls


I configure the editor to insert common "phrases" based upon characters typed thus far (like intellisense), using a version of Emacs. I imagine you could do something similar with other editors, such as binding some text to a function-key?

Short names, combined with a lack of namespace isolation, often makes code quite a bit harder to maintain over time. But, just recently I've started to realize that the percentage of code with a lifespan of more than a semester has been dropping at an increasing rate. Might the whole "long-term maintenance" thing actually be a sinking ship?