Re: [libstdc++] preliminary headers supporting decimal float in C++

[Janis Johnson <janis187 at us dot ibm dot com>]

On Tue, 2009-09-29 at 13:49 -0700, Benjamin Kosnik wrote:
>  > Should <decimal> go in with the standard headers or in ext?
> > 
> > So far my patch installs the new header files whether the target
> > supports decimal floating-point arithmetic or not.  Should I move the
> > configuration checks from the gcc directory to the top level and use
> > those to determine whether to install these files?
> 
> Good question. I would put current libstdc++ behavior into one of two
> buckets, given constraints given in N2849 section 2.4:
> 
> 1) put in std location, requires a flag to work. Ie, c++0x headers like
> std/unordered_map and -std=gnu++0x (__GXX_EXPERIMENTAL_CXX0X__). For
> you, this might mean something like -fdec-fp
> (__STDC_WANT_DEC_FP__) 
> 
> 2) put in a non-std location, don't require a flag to work. Ie, TR1
> headers like tr1/unordered_map.
> 
> From the GCC manual:
> http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html
> 
> It doesn't look like there is a flag, and __STDC_DEC_FP__ is not
> defined. So I would say you are trending towards style #2. This makes
> sense for other reasons as it looks like there might be facet additions
> which would mean you'd not want this support user-switchable.
> 
> So, I would suggest parking this stuff in
> 
> include/tr24732

Thanks, I'll change that.

> > The TR defines, within each of the classes decimal32, decimal64, and
> > decimal128, the following conversion:
> > 
> >   // 3.2.[234].4 conversion to integral type:
> >   operator long long() const;
> > 
> > Apparently there's a way to implement this if one knows enough about
> > C++, but providing this implicit conversion from a decimal float type
> > to long long allows further implicit conversions from long long to
> > other types, including float, double, and long double, which are not
> > supposed to be allowed.  Furthermore, a conversion from a decimal
> > float type to a generic float type that goes through long long
> > truncates the fractional part of the value which is rather
> > surprising.  This version of the patch leaves out that conversion and
> > provides a set of functions to convert to long long, which made
> > testing the rest of the functionality much easier. Any suggestions
> > for how to do with using the current (not C++0x) standard?  Or is it
> > OK to require the use of C++0x functionality with this extension?
> 
> I think it is not ok to require the use of C++0x with the
> decimal floating point extension. It is clearly designed with C++2003 in
> mind, and makes no use of C++0x features.

OK, that's what I would have thought.  Just checking.

> When you post testsuite files demonstrating this issue in detail I'll
> take a look at this overload issue.

I'll do that soon after a few other tweaks.

> > Section 4.2 of the TR says that implementations can support decimal
> > floating-point literals as a conforming extension.  My patch does that
> > by adding a constructor that takes as argument a scalar DFP type.
> > 
> > I've got lots of tests (not included here) but no documentation.  I'll
> > follow the recommendations in
> > http://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_style.html.
> 
> Here's what I suggest to get the documentation parts rolling.

Excellent, I was having some trouble figuring out how to document this.

<snip>

> > +  // ISO/IEC TR 24733  3.2.6  Conversion to generic floating-point
> > type.
> > +  float decimal32_to_float (decimal32 d);
> > +  float decimal64_to_float (decimal64 d);
> > +  float decimal128_to_float (decimal128 d);
> > +  float decimal_to_float (decimal32 d);
> > +  float decimal_to_float (decimal64 d);
> > +  float decimal_to_float (decimal128 d);
> > +
> > +  double decimal32_to_double (decimal32 d);
> > +  double decimal64_to_double (decimal64 d);
> > +  double decimal128_to_double (decimal128 d);
> > +  double decimal_to_double (decimal32 d);
> > +  double decimal_to_double (decimal64 d);
> > +  double decimal_to_double (decimal128 d);
> > +
> > +  long double decimal32_to_long_double (decimal32 d);
> > +  long double decimal64_to_long_double (decimal64 d);
> > +  long double decimal128_to_long_double (decimal128 d);
> > +  long double decimal_to_long_double (decimal32 d);
> > +  long double decimal_to_long_double (decimal64 d);
> > +  long double decimal_to_long_double (decimal128 d);
> > +
> 
> I have real questions about this C compatibility.

Yes, me too.

> From C++ N2849, usability intent remains obscured at least to me.
> 
> First, all these functions are declared with C++ linkage. Are C
> programmers to call the mangled name? After including the C++ header
> <decimal>? Why would any C programmer do this instead of
> casting? 
> 
> Second, overloaded functions like decimal_to_float, decimal_to_double,
> decimal_to_long_double are not actionable within C. Only the explicitly
> named functions like decimal32_to_float will be usable. Maybe this is
> just a typo in the standard.

I'll pass it on to the TR's author.  The TR has been approved, by the
way, and the latest version, dated 2009-08-28, doesn't have an "N"
document number.

> Third, mapping from C++ arg types decimal64 to _Decimal64 unclear.

This is weird.  If you include <float.h> then _Decimal32/64/128 are
typedefs for std::decimal::decimal32/64/128.  That doesn't happen
with <cfloat.h>.  The C TR adds the decimal float macros only if the
user has defined __STDC_WANT_DEC_FP__.  Section 2.5 of TR 24733 has
vague words about the new names being defined only if the user has
defined an unspecified macro, or putting different versions of standard
header files in a different place.

> Anyway.  
> 
> ?
> 
> Would probably arrange this differently.
> 
> include/tr24733/decimal
> include/tr24733/decimal.h -- just C stuff if needed, ie conversions to
> generic floating
> include/tr24733/decimal_operators.h -- all the overloads.
> 
Once again, thanks for the advice.

> best,
> -benjamin

Janis