
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_diff... 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