RE: [boost] LWG reaction: Header <cstdint>

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-11-04 17:50:25

Kevin Lynch's list sounds good to me.

I agree that it would be much nicer to produce C++ templated versions,
but perhaps PJP feels that there are more exciting things to do!

I have found it difficult to write code using NaN etc that looks portable.
Math functions would be nicer if it could include features like fpclassify?

Are HUGE_VAL, INFINITY already available as numeric_limits max and infinity?
(and implementations may well define numeric_limits in terms of MACRO
calls!)

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
Mobile [phone]
mailto:pbristow_at_[hidden]

> -----Original Message-----
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> Sent: Saturday, November 03, 2001 1:44 AM
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: Re: [boost] LWG reaction: Header <cstdint>
>
>
> At 05:25 PM 11/2/2001, Kevin Lynch wrote:
>
>  > ...
>  >I hope you don't mind me putting forward my laundry list in the math
>  >area:
>  >
>  >-> Import the new functions from math.h (this one is a no brainer, I
>  >think); most of the macros (isgreater, fpclassify, etc.) should really
>  >be turned into functions/templates (they are macros only because there
>  >is no overloading in C, and the overloading/template mechanisms are
>  >better suited to dealing with this functionality:  consider: int i;
>  >fpclassify(i);  this probably works, works silently, and can't be
>  >diagnosed as an error by the compiler.).
>  >
>  >-> Import the missing functionality from complex.h into <complex> (the
>  >inverse trig and hyperbolic functions, for example); also, any
>  >functionality in math.h that doesn't currently apply to complex should
>  >be applied where it makes sense to do so (log10, the gamma family,
>  >etc.);  see also the "future directions" chapter in the C99 standard;
>  >otherwise, complex.h obvious is superseded by <complex> and shouldn't
>  >come in.
>  >
>  >-> Floating point environment control in fenv.h should come in
>  >
>  >-> tgmath.h should NOT come in, since the macros are only there to cover
>  >for the lack of overloading
>  >
>  >-> it would be nice if all the preprocessor macros that define constants
>  >(HUGE_VAL, INFINITY, etc.) could follow the lead of boost/cstdlib and
>  >become constant variables.
>
> I guess at this early stage, one way to make your thoughts known would be
> to post the above on comp.std.c++ with a preface saying you
> understand that
> the C++ standards committee has begun to look at which C99 features to
> propose for the Library TR, and would like to add your math
> related laundry
> list.
>
> Another way would be for several Boosters to work out a detailed list of
> concerns, which we could then bring forward to the committee via
> the issues
> mechanism that will be in place.
>
> These aren't mutually exclusive.  In fact I hope you will post
> something on
> comp.std.c++ fairly soon, perhaps after waiting a bit to see if any other
> Boost members reply to your posting.  Later we at Boost can come
> up with a
> more formal issues list if we feel proposals put forward to the committee
> are lacking.
>
> In the past, the vast majority of C standard library features
> could just be
> brought forward "as is" into the C++ standard library.  I'm not so sure
> that is as good an approach this time around.  Boosters can do a real
> service to the C++ community by helping make sure sensible features are
> brought forward, but C++ oriented features are substituted where
> that makes
> more C++ sense.
>
> --Beman
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/