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