|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-26 13:42:49
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? 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) and no convenient way to resolve collisions in third-party
read-only code.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk