
Andrey Semashev <andysem@mail.ru> 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<<. 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. [snip] -- Jeremy Maitin-Shepard