[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale

["sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #7 from sebor at roguewave dot com  2008-01-11 03:37 -------
But that's just the libstdc++ interpretation of grouping and thousands_sep (no
offense). The C library paints a different picture.

If I want to write my own formatter/parser for numbers in the Bulgarian locale
that inserts '@' as my own thousands separator every 3 digits I can do it but
I have to drop down to C and get the grouping data from localeconv(). Not that
there's anything wrong with it but it would be nice if I could also do it in
C++ as well.

What I'm saying is that if the C library says localeconv()->grouping is "\3\3"
the C++ numpunct::grouping() shouldn't say it's something else.

I'm not sure this is something the C++ standard can do anything about except
acknowledge it as a limitation. But that doesn't mean that implementations
couldn't do better. For instance, numpunct could append some harmless special
character to its internal representation of grouping (say set it to "\3\3\0\0")
when thousands_sep is NUL. num_put would be instructed to look for the two
consecutive NULs in grouping and avoid inserting thousands_sep when NUL. Since
user-defined numpunct would almost certainly not return grouping terminated by
two NULs if such a facet with a grouping of "\3\3" and NUL for thousands_sep
num_put would insert the NUL as expected. Yes, it's a hack but it's one that
would work in the vast majority of cases: the implementation would pass anal
tests while behaving sanely in ordinary situations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733