Boost logo

Boost :

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-18 15:58:30


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<<.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk