Subject: Re: [boost] Boost.Math and Math Constants
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-12-08 05:23:34
>> It's a little bit of work up front, but if you define a custom type
>> with separate overloads for each arithmetic operator/operand type
>> combination (i.e. *(float), *(double), +(float), +(double), etc.) you
>> should be able to offer a single namespace with constants that
>> auto-promote (or demote) to the right type in expressions. That's
>> also easily extensible to user-defined storage classes such as an
>> extended precision float, and I think it's more maintainable since the
>> using declaration (which is now untyped) can't get out of sync with
>> the usage context. To prevent ambiguous overloads (in contexts where
>> the constant itself is supplied as an argument to a polymorphic
>> function, not in expressions), you can leave just one type (perhaps
>> double) as implicitly castable-to, with explicit casts for the others.
> A fundamental problem with proxies and things that try to rely on
> correct usage of conversion is that the conversion won't kick in when
> dealing with templates, as they do not matter when deducing template
> parameters. It's very easy to taint your types in such a way that a lot
> of machinery goes very very wrong.
Nod. There was some work on this I seem to remember after Paul's previous
constant-lib review failed, but it never really fully worked well enough...