Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-24 12:59:22


From: Paul A. Bristow <boost_at_[hidden]>
> This has been proposed before by the speed freaks,
> BUT it was widely felt that
> is was REALLY important to be able to write
>
> double area = pi * r * r;
>
> Without this, the constants would just not be widely used.

Aha! I had forgotten about this.

> But as you show, current compilers favour functions,
> so Michael Kenniston [Msk_at_[hidden]] can up with his cunning scheme
> (sadly too cunning for at least one compiler?)
>
> I could produce the functions you suggest, as I did before,
> but using the generator program.
> But I am reluctant to add further confusion.
>
> Do you believe that the code is invalid C++?
> (Or is the compiler wrong?)

Michael's code was rejected by EDG in strict mode, but is easily fixed.
The following version EDG believes to be conforming C++:

  template< typename Rep, typename Tag >
  struct constant {
    constant(){}
    operator Rep() const; // fully specialized for each Rep/Tag pair
  };

  struct pi_tag {};
  template<> inline constant< float, pi_tag >::operator float() const {
    return 3.141592653589793238462643383279502884197F;
  }

  template<> inline constant< double, pi_tag >::operator double() const {
    return 3.141592653589793238462643383279502884197;
  }

  namespace float_constants {
    constant< float, pi_tag > const pi;
  }

  namespace double_constants {
    constant< double, pi_tag > const pi;
  }

So I think Michael's proposal to be the cleanest. And from a standards
point of view, it should be possible to specify the interface so that
the implementation is open. The important thing is that the expression
float_constants::pi is convertable to float, not that it be any particular
kind of object. So
   static const double pi = 3.141592653589793238462643383279502884197F;
should also be a conforming implementation.

However, I'm still not sure why we need the various namespaces. Why not
just:

  template< typename Tag >
  struct constant {
     constant() {}
     operator float() const; // fully specialized for each Tag
     operator double() const; // fully specialized for each Tag
  };

  struct pi_tag {};
  template<> inline constant< pi_tag >::operator float() const {
    return 3.14159265358979323846F;
  }
  template<> inline constant< pi_tag >::operator double() const {
    return 3.141592653589793238462643383279502884197;
  }

And furthermore, if we aren't going to generate platform-specific
maximally precise constants, why not just:

  template< typename Tag >
  struct constant {
     constant() {}
     operator double() const; // fully specialized for each Tag
  };

  struct pi_tag {};
  template<> inline constant< pi_tag >::operator double() const {
    return 3.141592653589793238462643383279502884197;
  }

This is convertable to float, and the conversion can happen at
compile time.

> Paul
>
> PS I am right in concluding from these assembler examples
> that the code generated is not bad, but that peoples mileage
> may vary.

In all the cases I have tried any kind of inline function looks
the same to the code generator as a literal constant.

> And that comprehensive benchmarking is going to be difficult and
> contentious?

Perhaps. I don't see what is difficult about the benchmarking.

>
> > -----Original Message-----

> > From: Greg Colvin [mailto:gcolvin_at_[hidden]]
> > Sent: Wednesday, October 24, 2001 12:14 AM
> > To: boost_at_[hidden]
> > Subject: Re: [boost] Math constants for naive and gurus? - which
> > constants do you want?
> >
> >
> > > Many thanks for your work on this. Looks promising, but may
> > > be worth also producing the plain const double/float/long double files
> > > as well for the time being at least?
> > >
> > > Paul
> >
> > The plain const was actually less efficient for some platforms.
> >
> > The only problems I see with the template function approach is
> > the extra typing:
> >
> > v = pi
> >
> > is certainly easier than
> >
> > v = constant<pi_tag,double>
> >
> > but it is not amenable to more precise implementations.
> >
> > How about a compromise:
> >
> > v = pi<double>()
> >
> > and so on for all the other constants? I think this can be
> > made to work with even the most brain-dead compilers.
> >
> >
> >
> >
> > 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/
> >
> >
> >
> >
>
>
> 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/
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk