Re: [boost] Math Constants Library

From: wb_at_[hidden]
Date: 2001-04-27 09:40:24

I have been following this discussion with great interest, because my
own SIunits package incorporates a significant number of constants of
nature that would use comparable notation.

In my user community (largely composed of high-energy physicists),
there was a clear and unambiguous consensus when I raised the issue
three years ago of acceptable syntax for use of predefined constants.
A recent repetition of the (informal) survey led to the identical
conclusions:

  1)  When a default underlying type (whatever the package author has
  chosen) is acceptable, the syntax MUST be simply  pi , perhaps
  qualified by an explicit or implicit namespace.

  2)  When a specific underlying type is required by the user, the
  syntax may be no more complicated than  pi<long double> , again with
  namespace qualification if necessary.

  3)  Under no circumstances would functional notation such as  pi()
  be acceptable; it is perceived as "unnatural" and would, simply
  stated, be such a significant hurdle that it would inhibit use of the
  entire package!

I found this rather inflexible conclusion disappointing, but long ago
learned that, for most users, perception is reality:  if the user
community doesn't like a design, for whatever reason, the product won't
be used.

It was, frankly, very painful to come up with a means of accommodating
such a very firm mandate, but I believe I have done so.  If desired, I
would be pleased to discuss this issue (and perhaps others that may be
of interest) in the context of my SIunits package when Boost meets in
Copenhagen on Sunday.

        - WEB

Ed Brey <brey_at_[hidden]> wrote on Fri Apr 27 08:11:05 2001:

| From: <k.hagan_at_[hidden]>
| > I'm losing track of what has and hasn't been suggested. Have we
| > considered specialising a class template with a static member?
| >
| >    template<class T> class math
| >    {
| >       static T const pi;
| >    };
|
| I don't remember it being mentioned on the list, but I experimented with
| it a while back.  A problem I noticed is that the value cannot be
| specified inline in the template definition, causing most compilers to
| be unable to inline the constant in code or perform constant folding.
| Also, there is the question of whether a linker can exclude unused
| constants from the executable.  None of these are issues when using
| inline functions.
|
| On the other hand, using a constant for a constant instead of a function
| feels more natural.  The lure of inline functions comes from a practical
| matter addressing today's compilers' limitations.  Is there any
| realistic hope that compilers before too long would be able to handle a
| member function or constant equally well, such that the boost library
| could be practical in specifying a "cleaner" interface?  I noticed that
| gcc supports an extension allowing definition of a static const
| float-point type within the class definition, just like what allowed
| with ints.  However, I'm not familiar enough with gcc to know how to
| easily examine the code it generates to see what does with code that it
| tuned to make use of its extension.