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

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.