Re: [boost] Math Constants Library formal review results

From: Ed Brey (brey_at_[hidden])
Date: 2001-05-14 12:49:23

> "John Max Skaller" <skaller_at_[hidden]> wrote:
> >
> > 4. You do NOT need to satisfy all users.

Nor is it even possible.  One group of unhappy users will be those who
want a single interface.  Having the C (macro) interface and the C++
interface will make those users unhappy.  However, given a willingness
to forsake them, it might be possible to make everyone else happy.  Once
you've opened the door to multiple interfaces, you might as go all the
way and make as many interfaces as you need to cover all the
(conflicting) requirements.  Give pi to those who want
qualification-free (including parentheses) names.  Give pi() to those
who want inlining and constant-folding.  Give BOOST_PI to those using C.

To pull everything together (and make things look a little less designed
by committee) you could consider pi the primary interface, and consider
the other two "translator-helper" interfaces.  This would indicate that
pi()'s purpose is to provide a means way to get inlining and
constant-folding on compilers that can't yet do this with pi (it just
happens that almost all compilers currently have this limitation), and
BOOST_PI would be for compilers that don't like C++.

Of course, I'm not saying that three interfaces is definitely the way to
go.  Usually it is not.  However, in this case, since each interface is
extremely simple and since they parallel each other strongly, I'd say it
is probably the best of all tradeoffs.

Before engaging in the work necessary to put together a script to
produce the header files, I'd first like to see the documentation file
updated showing the proposed interface, rational, and usage examples.
The usage examples help make more clear nebulous questions like "Are
this going to be too many '<const double>'s in the code?"  Of course, it
doesn't need to list all constants, just having pi is fine.

A general point I'd like to raise deals with providing of derived
values, like pi/2.  Anything like this that the user could easily do
himself rubs me as bad interface design.  There will always some
constants missed that some users want and many constants included that
most users never use.  The interface will be neither minimal nor
complete.  By including just fundamental constants, it will be minimal,
and it will always be complete, because its mission will be more
narrowly scoped to just being a building block for the user.  (The only
exception to this are common terms that cannot be computed at compile
time, like sqrt(2).  Here, I see no choice but to go for the "what tends
to be useful" heuristic.)