RE: [boost] Math constantswith templates - language lawyers needed!

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-11-01 13:05:17

Ed has got to the nub of the problem with the fancy template magic I fear.

In essence is seems that compilers want the constructor
in strict mode, but that defining the constructor leads to linker and/or
code bloat.

Does this put the damper on using templates like forever?
Is this really the C++ language, or are the compilers wrong?

Views please (informed prefered!)

If this is the case, I suggest we go back to a simple

const long double pi = 3.141592653589793238462643383279502884197L;

format, at least for a first release.

I can also produce files with

const double pi =  3.14159265358979;

and const float pi = 3.141593F;

and I believe these may be useful to some,
despite the risk of confusion from multiple includes.

Paul

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

> -----Original Message-----
> From: Greg Colvin [mailto:gcolvin_at_[hidden]]
> Sent: Thursday, October 25, 2001 5:58 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math constants for naive and gurus? - which
> constants do you want?
>
>
> From: Ed Brey <edbrey_at_[hidden]>
> > From: "Greg Colvin" <gcolvin_at_[hidden]>
> >
> > >    namespace constants {
> > >
> > >       // an example constant, suitable for everyday abuse
> > >       static const struct pi_ {
> > >          pi_(){}
> > >          inline operator long double() const {
> > >             return 3.141592653589793238462643383279502884197L;
> > >          }
> > >       } pi;
> > >
> > >       // a generic constant generator
> > >       template<typename T, typename V> inline T constant(const V& v) {
> > >          return static_cast<T>(v);
> > >       }
> > >
> > >       // example specializations of the constant generator
> > >       template<> inline float constant(const pi_&) {
> > >          return 3.141593F;
> > >       }
> > >       template<> inline double constant(const pi_&) {
> > >          return 3.14159265358979;
> > >       }
> > >       template<> inline long double constant(const pi_&) {
> > >          return 3.141592653589793238L;
> > >       }
> > >    }
> >
> > Very interesting.  It shows promise of a single interface for
> specific and generic use.
> >
> > But alas, I can't make it work.  The compiler complains about
> multiple functions named "constant" that differ only by return type.
>
> EDG compiles this fine in --strict mode.  I've attached my test program.
>
> > There is also the same constructor issue that Michael's pattern
> has.  Here's the summary:
> > - With the constructor, VC generates code for each constant,
> whether referenced or not.
>
> I'd hate to give up a good interface just because some systems generate
> uneccessarily bad code.  I expect that on most systems we can tweak
> the implementation to solve such problems.
>
>
> > - Without the constructor, g++ complains that "pi" is uninitialized.
>
> Without the constructor EDG says
>
>         error: const variable "constants::pi" requires an
>           initializer -- class "constants::pi_" has no explicitly declared
>           default constructor
>         } pi;
>             ^
>
> But it doesn't complain without --strict.
>
> > There are a few possible solutions, however.  If VC is the only
> compiler that becomes inefficient in the face of the constructor,
> conditionally compile it away for VC.  If other compilers prefer
> to not see the constructor, change the definition of "pi" to
> >
> > double const pi_ pi = {};
> >
> > However, the {} notation breaks VC, so it would have to
> conditionally compiled out in that case.  I don't know what the notation
> does to the efficiency on other compilers.
> >
> > Of course, there is still the option of simply providing a
> bunch of simple double constants for non-generic uses, and then a
> separate simple function interface for generic uses, like this
>
> I'd prefer long double constants.
>
> > template<typename T>
> > struct constants {}
> >
> > template<>
> > struct constants<double> {
> >     static double pi() {return 3.14;}
> > }
>
> Yes, I like this as well.
>
> > Given the pitfalls with the fancy template magic, I'm starting
> lean towards the simpler approach.  This would cover the common
> cases quite well.  It doesn't provide for fanciness such as
> hand-crafted binary constants in the initial implementation, but I
> question the value of such items that are opaque to the compiler
> anyway (e.g. they are not subject to constant folding).
> >
> > If the interface is kept restrained, the implementation for the
> non-generic constants could be tweaked at any time.  Of course, we
> may find it more valuable to allow taking pointers and references
> to constants than to allow tweaking the implementation.  The
> former doesn't seem to be valuable very often, but then again,
> neither does the latter.
>
> Of course Beman says "Please do not make any design decisions for math
> constants based on 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/