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

2014-04-15 Thread Luke Allardyce
>> 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  and , 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
> C++11.

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.


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

2014-04-16 Thread Luke Allardyce
> 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.

Does that mean abi_tag will be enabled with separate compiler flag /
define rather than checking against the __cplusplus value?