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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-19 01:15:39

Andrey Semashev <andysem_at_[hidden]> 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