$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.