Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at