RE: [boost] Math constants for naive and gurus? - which constants do you want?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 14:02:46

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 26, 2001 3:42 PM
Subject: Re: [boost] Math constants for naive and gurus? - which constants
do you want?

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > I concieve non-specific constants as being not a part of any package;
but
> > rather something that a package might just need.
> > So I image a developer writting package A which happens to need pi. Now
> > assume pi isn't in boost, so he declares A::pi, not because 'pi' is
> > conceptually bounded to the package A but because it is needed by A.
> > Then some other developer is writting a package B, which uses A, and
which
> > needs 'radian'. 'radian' isn't in boost, nor A, so he declares
B::radian.
> > Package C needs a conveniently premultiplied 2*pi, so now we have
> C::two_pi;
> > And so on.. We end up having a bunch of non-specific common constants
> spread
> > in totally unrelated namespaces.
> >
> > I'm suggesting to put all general constants in a 'constants' namespace,
> and
> > to direct users in need of more general constants, to do the same. If
> there
> > are conflicts, they must be resolved. If I am right and those conflicts
> are
> > very unlikely and very easy to solve, I think this might be a better
> design.
>
> What problem does this solve?
I prefer to have: constants::pi,constants::radian and constants::two_pi than
A::pi, B::radian, C::two_pi.
But the later is a problem only if you have a problem wit it :-)
I certainly don't really mind it. I thought that users might complain.

> There is no way to exploit the duplication
> unless it's in a common header (i.e. it'd be in a common namespace in the
> former case)
Why? I can include "A:\general_constants.h", "B:\const.h" and
"C:\additional_constants.h"
and have them all put things in "namespace constants".

>
>and no convenient way to resolve collisions in third-party
> read-only code.
>
OK. I haven't thought about the case of a user of two conflicting
third-party read-only libraries...
And this overrides all my arguments, so that's it, I'm convinced!

(Ed showed it before but I couldn't see it)

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com