Cédric Venet <cedric.venet@student.ecp.fr> 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