From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-19 15:25:39


Phil Endecott wrote:
> Andrey Semashev wrote:
>> Lars Viklund wrote:
>> That's the key problem - it's like printf, thus makes extensibility for
>> user-defined types difficult, if possible.
>
> No, Boost.Format is based on iostreams internally, so it automatically
> makes use of any operator<< functions that have been defined for
> user-defined types. It is also unlike printf in that it largely
> ignores the actual letter in the format specifier; see the recent
> thread about uint8_t being formatted as a char even when %d is used,
> for example.

Ah, you're right. I must have messed it with some other printf-like
library I dealt with.

This looks like a very nice but heavy solution to me. If only it could
perform at least as fast as regular stream output... I'm still finding
myself using itoa & co. instead of sprintf, lexical_cast or
ostringstream quite often just because it's easy and fast.

I think Boost.Format performance could be noticeably higher if the value
concept of the formatter was separated from the formatting
functionality. This is better to be shown in example:

   // This creates an object that may be used like
   // current boost::format object and may be implemented similarly
   boost::formatter fmt("%1%, %2%, %3%");

   fmt % a % b % c;
   std::cout << fmt.str();

   // The "format" function returns an object of unnamed type,
   // which is essentially a tuple of pointers to the formatting
   // string and references to the arguments passed
   std::cout << boost::format("Hello: %1%, %2%, %3%", a, b, c);

The advantage of boost::format above is that there are no additional
dynamic allocations and neither format string (or its part) nor a, b or
c are copied. The drawback is that the same argument may be output
multiple times if its identifier is mentioned more than once in the
format string. But I think, this case is quite uncommon.

> All of the current formatted I/O mechanisms have their problems. I
> don't have any good ideas about how to fix them, but maybe variadic
> templates will give someone a clever idea...

With variadic templates Boost.Format could become a true formatting
manipulator, taking all formatted parameters as arguments rather than by
feeding operator% (see boost::format in my code snippet above). It seems
to me there's too much compromise in this operator usage, and the size
of the "Choices made" section tells me I'm right.