-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Bindels Sent: Thursday, June 21, 2007 2:54 AM To: boost@lists.boost.org Subject: Re: [boost] [rfc] I/O Library Design
On 21/06/07, Johan Råde <rade@maths.lth.se> wrote:
Mathias Gaunard wrote:
Any application that process or display non-trivial text (meaning something else than options) should have internationalization.
Is there any performance penalty when using UTF-8 instead of ASCII, for instance when searching text? If there is not, then I'd be happy with an UTF-8 / UTF-16 / UTF-32 solution.
[Joe] I think the data formatting needs to be cleanly separated from the actual I/O layer and instead performed in some sort of string class. Much of the time, I want to format data, but don't want to send it to an I/O layer. Instead I want to display it with a GUI; put it in a packet to be sent later; or some other operation. Performing the data formatting in the string class means the I/O library wouldn't have to care about Unicode issues. Any formatting issues would be taken care of by an appropriate string class. I would prefer that something like boost format be part of the string class, though I prefer the specifiers from C# to the specifiers actually used by boost format. C# also allows custom formatters to be created and used and I like that idea. Now, I am obviously not talking about using boost format as is because it uses streams and I think that is too slow in general. Having said all that, it would be great if the I/O system could automatically delegate the formatting so that the user doesn't explicitly have to create a string to do I/O. That is, I would want to do some equivalent of Write("X = {0:d}", 53) and have that come out, but I think I would like it to automatically create an appropriate string, do the formatting, and then dump the results out (or at least use the same mechanisms) rather than have the I/O system do the formatting. As far as everything else, using some sort of interface on a string class would allow various Unicode encodings to be included as they are written. I hesitate to base much on Unicode because there have been a plethora of Unicode classes proposed and none of them have seen the light of day as far as I can tell. This tells me that there are too many issues that crop up to be basing the whole I/O system upon. Anyway, these are just some random thoughts I have had about the issue. joe