RE: [boost] Re: Math Functions: Basic building blocks...

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-01 12:22:15

----- Original Message -----
From: Eric Ford <eford_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, September 28, 2001 9:54 PM
Subject: [boost] Re: Math Functions: Basic building blocks...

> > Borland C++ 5.5.1 contains only double and long double (with the 'l'
> suffix)
> > versions.
> > There is no float overload.
> >
> > I've looked at the source files and (at least for the functions
> cos/cosl and
> > abs/absl that I checked) the implementation is truly double/long
> double.
>
> Thanks for this report.  Anyone else wishing to help out with reports
> on other compilers, that would be appreciated.  I could test the
> vendor provided solaris and sgi compilers, although they're likely to
> be out of date versions.
>
> > I'm not sure if macro flags would work in all cases. How about a
> separate
> > 'cmath_compatibility.hpp' header, compiler specific, that defines
> all the
> > missing overloads? That way, standard_functions.hpp can just pretend
> all the
> > overloads are present.
>
> I worry about that allowing unexpected implicit conversions.  While
> that would probably be ok with Borland.  On compilers that don't
> provide long double versions of functions, I'm not sure this is a good
> idea.  I think the user should have to specify that a double precision
> version is acceptable.  Specialization allows for this.
>
I was thinking of a *private* header, just in order to ease the
implementation of 'standard_functions.hpp'.
This header would contain the definitions of those functions NOT provided by
cmath, so the conversions required would be needed anyway.
This header would be constructed such that the *true* function being called
is the same compiler-provided function that would be called if a macro flag
were used. I just think this is more flexible than a macro switch approach,
but the effect should be exactly the same.

For example, I'm thinking about something like this:

boost\math\standar_functions\detail\cmath_compatibility.hpp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

namespace boost {
namespace math {
namespace standard_functions_detail {

//
// Each of the macro flags below correspond to each of the standard math
functions that should be declared
// in the header <cmath>.
// Define each of this macros for each function NOT DECLARED in <cmath>
// (or any other header provided by the compiler vendor)
//
// #define BOOST_NO_HAS_COSF
// #define BOOST_NO_HAS_COSL

// Compiler specifics

#if defined __BORLANDC__
  #define BOOST_NO_HAS_COSF
#endif

// Missing functions declaration

#ifdef BOOST_NO_HAS_COSF
   inline float cosf ( float v )

      return ::boost::numeric_cast<float>(::std::cos(v) ) ;  } // assumes
existence of double std::cos( double);
   }
#endif

#ifdef BOOST_NO_HAS_COSL
   inline long double cosl ( long double v )

      return ::std::cos( ::boost::numeric_cast<double>(v) )  ;  } // assumes
existence of double std::cos( double);
   }
#endif

} // namespace standard_functions_detail
} // namespace math
} // namesapce boost

Notice that I considered providing individual switches, becuase I think that
non-conformance might be at the function level, not the group level
(float/double/long double)

> Or were you planning to provide an actual implementation of the
> various long double functions that were missing from libraries?  I
> think that would be great, but that's more than I'm willing to do.
>

No, I wasn't thinking about that, because that should take into account the
target platform and not only the compiler; so that's a whole different
story. (it would be trival in the case of Borland/Windows, but no so trivial
in general case)

Regards,

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com