[PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.

[Luke Allardyce]

It looks like the new standard also requires the precision to be
ignored for hexfloat

>For conversion from a floating-point type, if floatfield != (ios_base::fixed | ios_base:: scientific), str.precision() is specified as precision in the conversion specification. Otherwise, no precision is specified.

So perhaps something like

Index: libstdc++-v3/src/c++98/locale_facets.cc
===================================================================
--- libstdc++-v3/src/c++98/locale_facets.cc (リビジョン 208802)
+++ libstdc++-v3/src/c++98/locale_facets.cc (作業コピー)
@@ -69,19 +69,23 @@
     if (__flags & ios_base::showpoint)
       *__fptr++ = '#';

-    // As per DR 231: _always_, not only when
-    // __flags & ios_base::fixed || __prec > 0
-    *__fptr++ = '.';
-    *__fptr++ = '*';
+    ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;

+    if (__fltfield != (ios_base::fixed | ios_base::scientific)) {
+      // Precision used if flags != hexfloat
+      *__fptr++ = '.';
+      *__fptr++ = '*';
+    }
+
     if (__mod)
       *__fptr++ = __mod;
-    ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;
     // [22.2.2.2.2] Table 58
     if (__fltfield == ios_base::fixed)
       *__fptr++ = 'f';
     else if (__fltfield == ios_base::scientific)
       *__fptr++ = (__flags & ios_base::uppercase) ? 'E' : 'e';
+    else if (__fltfield == ios_base::fixed | ios_base::scientific)
+      *__fptr++ = (__flags & ios_base::uppercase) ? 'A' : 'a';
     else
       *__fptr++ = (__flags & ios_base::uppercase) ? 'G' : 'g';
     *__fptr = '\0';


Also the old standard seems to require that ios_base::fixed |
ios_base::scientific (or any other combination) falls through to the
uppercase test; I was trying to use abi_tag for a solution as not only
would two versions of _S_format_float be necessary, but also num_get
due to the pre-instantiated templates for <char> and <wchar>, which
led me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642. It might
just be more trouble than it's worth.

On 28 March 2014 01:27, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 27/03/14 17:00 +0100, Rüdiger Sonderfeld wrote:
>>
>> Hello Jonathan,
>>
>> thanks for your comments.
>>
>>> N.B. patches to the ChangeLog rarely apply cleanly (because someone
>>> else may have changed the ChangeLog since the patch was created) so
>>> the convention is to send the ChangeLog entry in the email body, or as
>>> a separate attachment, or by using 'git log -p @{u}..' so the commit
>>> log shows it, rather than as part of the patch.
>>
>>
>> Yes, ChangeLog's can be a bit of a pain.  I removed the ChangeLog from the
>> patch.  But FYI there is a ChangeLog merge driver hidden in gnulib, which
>> can be helpful when dealing with ChangeLog files in git (and potentially
>> other version control systems)
>>
>>
>> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
>
>
> Yes, I use that myself, and generate patches with the 'git lgp'
> command shown at http://gcc.gnu.org/wiki/GitMirror
>
>
>>> We could document that (fixed|scientific) has that effect in c++98
>>> mode.
>>
>>
>> Where should it be documented?
>
>
> Probably somewhere in doc/xml/manual/io.xml but I'm happy to do that
> once the patch is committed if you like.
>
> Thanks for the updated patch, I will try to remember to commit it when
> stage 1 starts. If you don't get a mail from me then please ping me as
> a reminder.
>
>