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
>> 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
>>> 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
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk