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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-19 16:17:49

Scott Woods wrote:
> ----- Original Message ----- 
> From: "Jeremy Maitin-Shepard" <jbms_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, June 19, 2007 5:15 PM
> Subject: Re: [boost] [rfc] I/O Library Design
> 
> [snip]
>> Indeed, it is true that printf is not perfect, because it requires that
>> the arguments are referenced in the same order that they are specified
> 
> [snip]
>>> Internationalization is, indeed, an issue. But to my mind, if we're
>>> speaking of a Standard proposal, we need a more well-thought solution to
>>> this problem, and neither current streaming IO nor C-style IO suits
>>> it.
>> I do agree that a well thought out proposal is needed, and that neither
>> iostreams nor C printf are suitable.  I'll be happy with anything that
> 
> Interesting. Would be real keen to know what the actual goals would
> be for such a proposal. I can see several excellent proposals arising
> from the ideas mentioned here, but each would have different goals.

 From my point of view we have touched two problems in the discussion: 
the ability to easy and efficiently format things into text or octet 
strings and internationalization support. These two tasks are attempted 
to be solved by the current C++ IO implementation, but the attempt is 
suboptimal in various ways.

I think, there should be two proposals, each aimed to solve the 
corresponding problem. The first one should propose an easy and 
efficient way of formatting data into strings and the second one to 
provide a support for i18n. The latter means, for example, an ability to 
select and format messages to user in a language, known in run time. 
This may involve things like resources (may be dynamically loaded) and 
Unicode support, but the key requirement is that there should be no need 
to modify application's source code to run it in another language.

This proposal separation doesn't mean that they are not related. We may 
eventually end up with a single solution to the both problems. But for 
now I see them as a different issues with different requirements to 
implementation (for example, our discussion of printf and streaming 
approach to formatting shows that the single format string compromises 
performance for general formatting cases, but may help to solve i18n 
problem).

I hope, I've answered your question.

Meantime, I can see now that we're heading a bit off-topic from the 
original post, since the initial discussion began on a new IO 
architecture proposal, which is a bit aside from the problems I 
mentioned above. Sorry, Sebastian.