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

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

Cédric Venet <cedric.venet_at_[hidden]> writes:

>> 
-> 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<<
>> 
>> > I'd rather disagree with you here. Operator<< gives a great advantage
>> of
>> > extensibility which printf cannot offer. I can define my own classes
>> 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<<.

> Supposing I want some function which take a formatting chain and an arbitrary
> number of parameter to pass it to the new printf and then do something (usually,
> add a prefix, a new line or throw an exception). How can I do the forwarding in
> C++2003 (without defining x overload). Perhaps fusion provide some support for
> this?

Yes, to actually get the syntax printf(...), you would indeed need
either a lot of overloads, or vararg template support.  A lot of
facilities in boost, such as bind, have the same limitation, though.

> Motivation:

> Template<class T... >
> Void PrintAndThrow(const char* c, T... args) {
> 	Cout.printf(c,args);
> 	Throw somethings;
> }

> Another things is what would be the type of the format string: a const char* or
> std::string?

I'm not sure about this.  It makes the most sense for the format string
to be in the same encoding as the output text (which might likely be
UTF-8 or UTF-16), so it is not clear what type would be used to
represent such a string.  There is also the issue that it is
inconvenient to specify a string literal in C++ that is encoded in a
particular encoding (the encoding used varies by compiler, platform,
locale settings).

> Which would need parsing each time (an no compile time checking) or
> a complex type build by expression template (I am thinking about some proto DSL
> here).

It would require parsing each time, but provided that the syntax is
reasonably simple, the parsing overhead may be very small.  The lack of
compile-time checking is annoying, although some compilers might provide
it as a hack, and at least there can be runtime type checking, unlike
with C printf.

> It would be more complex and slower to compile, but it as some
> advantage.

I think that any sort of complex expression template framework would be
totally out of the question, because the increase in compile-time would
make the library so inconvenient to use that it would just not be worth
using at all.

> This problem don't existe with << since we treat one object at a time
> which is the reason reordering is impossible and internationalization difficult.

-- 
Jeremy Maitin-Shepard