We definitely need to keep an eye on this issue while the new stream
design is in flux. Transcoding Windows I/O is a major application.
Andrei
On 9/17/10 12:04 PM, Shin Fujishiro wrote:
Thank you for picking up the topic!
Andrei Alexandrescu<[email protected]> wrote:
Regarding transcoding output, please let me know I understand the
problem correctly: under Windows (and possibly under other OSs under
certain configurations) the console is not UTF and cannot be reasonably
forced to be UTF.
Yes. Neither input or output isn't UTF under Windows.
I think for such situations, the classic Decorator-based design with
stacked interfaces works well: you have a TranscodingStream wrapping a
NativeStream or a UTFStream or whatever.
The streaming interface question comes again, i.e. what is the interface
that allows such stacking with minimal cost in efficiency?
The cost is minimal when the transcoder has direct access to both I/O
device and buffer. I mean, there would be no redundant copy involved:
ubyte[N] tmp = void;
convert(buffer, tmp);
device_write(tmp);
So, the best layer for doing converted (or filtered) I/O is the stream
buffer. But I feels like it's not quite right... buffering layer might
be too 'low level' for character code conversion.
Shin
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
