This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Luke Allardyce <lukeallardyce at gmail dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Rüdiger Sonderfeld <ruediger at c-plusplus dot de>, libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 16 Apr 2014 11:21:40 +0100
- Subject: Re: [PATCH v2] libstdc++: Add hexfloat/defaultfloat io manipulators.
- Authentication-results: sourceware.org; auth=none
- References: <20140327133723 dot GA13599 at redhat dot com> <1901588 dot qodTErPe42 at descartes> <20140327162714 dot GA13192 at redhat dot com> <CAFW6PZC0u5=i-KqQZZsbkmg5iWr6u2WVnnBQVqG8V2Bt6oOzOg at mail dot gmail dot com> <CAH6eHdTyy5_98zcGCDNOkwTnfmLYHnb+r9m=ktNMCDw2LXWzqA at mail dot gmail dot com> <CAFW6PZAA_ujYRMWB8DqytG99=G=a-MbONyf9SkqHa02YUi6htg at mail dot gmail dot com>
On 16/04/14 14:26 +0900, Luke Allardyce wrote:
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.
I don't think we need to worry about that, if I understand correctly
the combination of fixed|scientific has unspecified behaviour in
C++03, so we can make our implementation do exactly what it does in
It seems to me that it is well defined, going from [lib.facet.num.put.virtuals]
6 All tables used in describing stage 1 are ordered. That is, the first line whose condition is true applies.
A line without a condition is the default behavior when none of the earlier lines apply.
So fixed|scientific would be equivalent to specifying neither
according to table 58, and the resulting specifier would be %g or %G
depending on whether uppercase is set or not.
Thanks, I was wrong about that.
Then I think we should just bite the bullet and provide the new
behaviour. If we do have an abi_tag on those types in the next release
then we can preserve the old behaviour in the old ABI and use the
C++11 semantics for the abi_tagged type, which will be used for both
C++03 and C++11 code. I am not too concerned that people who use a
meaningless modifier in C++03 code get the C++11 behaviour. If they
really want %g or %G then they shouldn't use fixed|scientific.