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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-18 23:48:57

Jeremy Maitin-Shepard wrote:
> Andrey Semashev <andysem_at_[hidden]> writes:
> 
>> Ion Gaztañaga wrote:
>>> Sebastian Redl wrote:
> 
>> [snip]
> 
> -> Hard formatting: printf/scanf are much easier to use and they don't 
>>> need several hundred of function calls to do their job. The operator<< 
>>> overloading is also a problem if each call needs some internal locking. 
>>> A formatting syntax that can minimize the locking needs would be a good 
>>> choice. I would be really happy with a type-safe printf (variadic 
>>> templates to the rescue).
> 
>> I'd rather disagree with you here. Operator<< gives a great advantage of 
>> extensibility which printf cannot offer. I can define my own classes and 
>> overload the operator for them, and the IO system will work as expected 
>> with my extensions. The same thing with operator>> and scanf.
> 
> That is not a real issue.  You can easily provide a mechanism for
> supporting user-defined types on top of a printf/scanf-like interface,
> e.g. by specializing a template, or overloading some other function that
> is called by the implementation of the formatting system.  So ease of
> supporting user-defined types is not an argument in favor of operator<<.

I agree with Cedric's reply to this. Specialization is too much a burden 
and, in fact, is intrusive. As for overloading some external function, 
we already have this function, it's operator<<.

> A key advantage of a printf interface, in addition to being much less
> verbose, is that it is much more convenient for internationalization;
> under that interface, internationalization of messages is usually
> possible simply by changing the format strings, an approach that is well
> supported by packages like gettext.  Using the operator<< interface,
> however, in general it is necessary to change the source code in order
> to support internationalization, because in addition to being more
> difficult to correctly translate a small snippet of a message instead of
> an entire format string (it may be necessary for the translator to look
> at the source code context to determine how to translate it), it may not
> even be possible due to differences in grammar between languages.

Printf is not a solution since there may be radical differences in 
phrase composition in different languages.

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.