Re: [boost] [rfc] I/O Library Design

From: Greer, Joe (jgreer_at_[hidden])
Date: 2007-06-21 08:29:10

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Peter Bindels
> Sent: Thursday, June 21, 2007 2:54 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [rfc] I/O Library Design
> 
> On 21/06/07, Johan Råde <rade_at_[hidden]> 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