[boost] [format] Inconsistencies with printf

Subject: [boost] [format] Inconsistencies with printf
From: Sam Partington (sam.partington_at_[hidden])
Date: 2009-01-27 12:18:38

Hi,

There are still several differences between printf and Boost.Format :

http://www.boost.org/doc/libs/1_37_0/libs/format/doc/format.html#printf_differences

Whilst I realise that it is difficult to fully meet the printf
formats, is there likely to be an improvement in this area?

We are using Boost.Format to replace a lot of existing sprintfs, so
having exact compatiblitity would be very useful.  At the least it
would be nice if unsupported options were ignored silently.  For
example we had the format string "%8.8x" silently pad the result with
spaces rather than zeros, which rather surprised us, as we have all
exceptions switched enabled.

I have managed to add a rather poor emulation of the precision with
integral types. It only works correctly when the width and the
precision are the same, but at least it will raise an exception in
other cases, and if exceptions are disabled it prefers to pad with
zeros as that breaks our code less.  I realise that others mileage may
vary. But for myself I prefer this non-silent version.

i.e. :

"%8.8x" % 0x1234 == 00001234
"%8.3x" % 0x1234 == 00001234 *
"%3.8x" % 0x1234 == 00001234

* sprintf would return "    1234" here.

parsing.hpp:267 : In function parse_printf_directive just before the
switch on the type char.

// begin SRP added
if(precision_set && strchr("xXpoudi", int(wrap_narrow(fac, *start, 0))))
{
    if (fpar->fmtstate_.precision_ != fpar->fmtstate_.width_)
    {	// we only support the precision on integral types if the width and
        // the precision are identical.  If exceptions are enabled then
        // throw, but if not do something vaguely sensible, and pad with
        // zeros up to the largest width specified
        maybe_throw_exception(exceptions, start-start0+offset, fstring_size);
        if (fpar->fmtstate_.precision_ > fpar->fmtstate_.width_)
        {
            fpar->fmtstate_.width_ = fpar->fmtstate_.precision_;
        }
    }				
    fpar->pad_scheme_ |= format_item_t::zeropad;
}
// end SRP added

One of the goals of the Format library is to "provide
printf-compatibility, as much as it makes sense in a type-safe and
type-extendable context."

Is this goal still valid?

Sam