Improving D's support of code-pages
kirklin.mcdonald at gmail.com
Sat Aug 18 21:19:07 PDT 2007
Walter Bright wrote:
> Kirk McDonald wrote:
>> Walter Bright wrote:
>>> The problem is that whatever is sent to a file should be the same as
>>> what is sent to the screen. Consider if stdout is piped to another
>>> application - what should happen?
>> Let's say there's a function get_console_encoding() which returns the
>> console's current encoding. I'm simply proposing that this:
>> char str = something();
>> Should end up being equivalent to this:
>> std.cstream.dout.writefln(encode(str, get_console_encoding()));
>> So, to answer your question, if you use std.stdio.writefln, you will
>> send a string encoded in the console's default encoding to the other
>> application's stdin. This is the encoding the other application should
>> be expecting, anyway (unless it isn't; code pages are annoying like
>> In any event, if you explicitly want to output something in a
>> particular encoding, this /will/ work:
>> std.stdio.writefln(encode(str, whatever));
>> This is because encode() returns a ubyte, and writefln should print
>> the data in ubytes directly, as I suggested in my original post for
>> this precise reason.
> stdio can detect whether it is being written to the console or not.
> That's fine. The problem is:
> will generate one kind of output.
> foo | more
> will do something else. This will result in a nice cascade of bug
> reports. There's also:
> foo >output
> cat output | more
> which will do something else, too.
Pardon? I haven't said anything about stdio behaving differently whether
it's printing to the console or not. writefln() would /always/ attempt
to encode in the console's encoding.
Pyd: Connecting D and Python
More information about the Digitalmars-d