Re: [boost] TODAY: Math Constants library formal review starts

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-04-23 15:12:07

I've had a quick look, and I'd like to see the library changed and then
re-reviewed, because major interface changes seem to be necessary:

 - I think the C-style macros are not acceptable as the only interface
for a boost submission.  The "default" mode of use should not defined
any macros (except possibly internal helpers).

 - I second Matt Austern in that the interface must allow library vendors
to provide a platform-optimized implementation.  The boost reference
implementation should stick with a portable implementation, though.

 - I favor the "boost::math" namespace for the constants.  If someone
needs these constants repeatedly in some scope, there's always the
option to employ a using-declaration.

 - I'd like to see the source files rearranged, and I'd like to see
the "generator" program included in the submission, at least for
archival purposes.  Sure, it uses NTL.  The non-essential "generator"
and "comparison" files ("knuth") should go to a subdirectory, such
as "tools".  ("src" seems a bad choice, because an automated boost
library build could mistake that for the library source directory)

 - I believe that filenames with spaces are a bad idea, can be easily
avoided (use the underscore) and thus should be avoided.

 - Filenames of boost submissions tend to follow the
lowercase_underscore convention of boost identifiers.  I'd be pleased
if we could thusly avoid MixedCase filenames for general
consistency.

 - Previous discussions during this review seems to have avoided the
"naming scheme" topic, which I'd like to emphasize once more:  Please
expressly define a naming scheme for the constants, in particular
when having values such as "2/3 pi" and "sqrt of pi".  It may not
be perfectly unambiguous, but there should be *something* documented.

 - A procedural remark:  I find it unfortunate that such major
interface issues show up as late as this formal review.  I would have
preferred the code to be available before scheduling the review.