This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Interpretation of 22.2.6.2.2.2


Hi,

consider this testcase (excerpted from one submitted by Peter Schmid as part of
libstdc++/5708):

#include <sstream>
#include <iostream>
#include <locale>
class My_money_io : public std::moneypunct<char,false>
{
public:
  char_type do_decimal_point() const { return '.'; }
  char_type do_thousands_sep() const { return ','; }
  std::string do_grouping() const { return "\003"; }

  std::string do_negative_sign() const { return "()"; }

  int do_frac_digits() const { return 2; }

  pattern do_neg_format() const
  {
    static pattern pat = { { symbol, space, sign, value } };
    return pat;
  }

};

int main ()
{
  using namespace std;
  typedef ostreambuf_iterator<char> OutIt;

  locale loc(locale::classic(), new My_money_io);

  bool intl = false;

  string val("-123456");
  char fill = '*';
  const money_put<char,OutIt>& mp  =
    use_facet<money_put<char, OutIt> >(loc);

  ostringstream fmt;
  fmt.imbue(loc);
  OutIt out(fmt);
  mp.put(out,intl,fmt,fill,val);
  cout << "val: " << val << " fmt: "<< fmt.str() << endl;
}

The output is:
val: -123456 fmt:  (1,234.56)
                  ^
          notice the space here

On the other hand a different respected implementation outputs:
val: -123456 fmt: (1,234.56)

I think the latter behaviour is dictated by an interpretation of 22.2.6.2.2.2
which considers the 'space' and 'none' fields in the same way, filled with the
fill char for internal formatting (if len < width, of course), not relevant
otherwise.

In the current libstdc++-v3, on the other hand, locale_facets.tcc, lines
1226-1234:

  case money_base::space:
    // At least one space is required, but if internal
    // formatting is required, an arbitrary number of
    // fill spaces will be necessary.
    if (__testipad)
      __res += string_type(__width - __len, __fill);
    else
      __res += __ctype.widen(' ');
    break;

Intuitively, it seems to me weird that the standard dictates a 'plain' space in
one case (internal formatting and len < width) and 'fill-type' spaces otherwise.
I cannot see a neat support to this interpretation in the standard. Also, for
non-internal formatting we end up having both a 'plain' space and some more
'fill-type' ones.

Are we really doing the right thing?

Thanks,
Paolo.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]