Boost logo

Boost :

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


Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
+44 1539 561830
Mobile +44 7714 33 02 04

> -----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: Unsubscribe:

Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at