This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

### 671. precision of `hexfloat`

Section: 28.4.3.3.3 [facet.num.put.virtuals] Status: C++11 Submitter: John Salmon Opened: 2007-04-20 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [facet.num.put.virtuals].

View all other issues in [facet.num.put.virtuals].

View all issues with C++11 status.

Discussion:

I am trying to understand how TR1 supports hex float (%a) output.

As far as I can tell, it does so via the following:

8.15 Additions to header `<locale>` [tr.c99.locale]

In subclause 28.4.3.3.3 [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line:
`floatfield == ios_base::scientific %E`

add the two lines:

>     floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
>     floatfield == ios_base::fixed | ios_base::scientific %A 2

[Note: The additional requirements on print and scan functions, later in this clause, ensure that the print functions generate hexadecimal floating-point fields with a %a or %A conversion specifier, and that the scan functions match hexadecimal floating-point fields with a %g conversion specifier. end note]

Following the thread, in 28.4.3.3.3 [facet.num.put.virtuals], we find:

For conversion from a floating-point type, if `(flags & fixed) != 0` or if `str.precision() > 0`, then `str.precision()` is specified in the conversion specification.

This would seem to imply that when `floatfield == fixed|scientific`, the precision of the conversion specifier is to be taken from `str.precision()`. Is this really what's intended? I sincerely hope that I'm either missing something or this is an oversight. Please tell me that the committee did not intend to mandate that hex floats (and doubles) should by default be printed as if by %.6a.

[ Howard: I think the fundamental issue we overlooked was that with %f, %e, %g, the default precision was always 6. With %a the default precision is not 6, it is infinity. So for the first time, we need to distinguish between the default value of precision, and the precision value 6. ]

[ 2009-07 Frankfurt ]

> Leave this open for Robert and Daniel to work on.

> Straw poll: Disposition?

> - Default is %.6a (i.e. NAD): 2
> - Always %a (no precision): 6
> - precision(-1) == %a: 3

> Daniel and Robert have direction to write up wording for the "always %a" solution.

> [ 2009-07-15 Robert provided wording. ]

[ 2009-10 Santa Cruz: ]

> Move to Ready.

Proposed resolution:

Change 28.4.3.3.3 [facet.num.put.virtuals], Stage 1, under p5 (near the end of Stage 1):

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

[ Kona (2007): Robert volunteers to propose wording. ]