This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 23 [utilities] Status: NAD Submitter: Great Britain Opened: 2017-02-03 Last modified: 2017-07-17
Priority: Not Prioritized
View all other issues in [utilities].
View all issues with NAD status.
Discussion:Addresses GB 45
If P0067R4 is applied consider how to parse hexadecimally:
to_chars(beg, end, 42, 16); 16 for hex
to_chars(beg, end, 4.2, true); true means hex
to_chars(beg, end, 4.2, chars_format::hex);
to_chars(beg, end, 4.2, chars_format::hex, 2);
That is: We have 3 different formats to specify hex depending on value types and whether to use precision. Which application programmer should remember this?
May be even worse (I am not sure):
to_chars(beg, end, 4.2, 16);
would silently convert 4.2 to 4 and
to_chars(beg, end, 4, chars_format::hex);
would silently convert 4 to 4.000000.
Proposed change: The various options should be harmonized, possibly by use of an extended enum approach, having the values: dec, hex, scientific, fixed, general with dec (new!) as default for integral values and general for floats
[2017-02-23, Jens Maurer comments]
This issue is NAD; the facility was redesigned with these considerations in mind before it went into the working draft.
[ 2017-06-26 Moved to Tentatively NAD after 5 positive votes on c++std-lib. ]