Andrey Semashev <andysem@mail.ru> writes: [snip]
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<<.
The point is simply that the burden is in fact exactly the same for both mechanisms, so that issue cannot be used in favor of one or the other.
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.
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 in the source code, and that they can only be referenced exactly once. Very simple extensions can be used to support that, however, such as allowing arguments to be referenced by number (or perhaps by a name) and thereby provide a suitable solution.
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 is efficient (both run-time and compile-time), supports internationalization, user-defined types, and isn't excessively verbose. It just seems that starting with a printf-like mechanism (or better yet, existing facilities in libraries like IBM ICU that resemble printf), and then trying to determine how to support all of the desired objectives, rather than starting with iostreams, may be a better idea. -- Jeremy Maitin-Shepard