Re: [boost] is_nan

From: John Maddock (john_at_[hidden])
Date: 2006-07-26 04:55:13

Howard Hinnant wrote:
> On Jul 25, 2006, at 1:45 PM, Howard Hinnant wrote:
>
>> namespace Mine
>> {
>>
>> struct Person {};
>>
>> struct Female : public Person {};
>>
>> bool isnormal(const Person&);
>>
>> }
>>
>> int main()
>> {
>>      using namespace boost;  // for boost::bind (just as an example)
>>      Mine::Female Jane;
>>      bool b = isnormal(Jane);
>> }
>
> If this code doesn't make you nervous (because of the using
> directive), the related code below might:
>
> namespace Mine
> {
>
> struct sense_of_humor {};
>
> struct Person : private boost::optional<sense_of_humor> {};
>
> struct Female : public Person {};
>
> bool isnormal(const Person&);
>
> bool foo()
> {
>     Female Jane;
>     return isnormal(Jane);
> }
>
> }  // Mine
>
> int main()
> {
>     Mine::foo();
> }
>
> Again, isnormal will get hijacked by boost::isnormal(T) if it is in
> the translation unit (and in namespace boost and not somehow
> constrained).

Won't bool isnormal(const Person&) be the better overload and therefore the 
one called?  The worst I can see happening is an "ambiguous overload" error.

BTW "isnorm" (note the spelling) should be in boost::math:: not boost:: so 
the risk is somewhat reduced.

> template <class T>
> typename enable_if
> <
>     std::numeric_limits<T>::is_specialized,
>     bool
>>>> type
> isnormal(T t) {...}

Sigh, yes I can see the point of that, I'm fighting against it because it 
would break *my* code: it uses numeric types (NTL::RR) for which 
std::numeric_limits<> support is not appropriate, 'cos the precision is not 
a compile time constant.  I could use another traits class that defaults to 
std::numeric_limits<T>::is_specialized but provides a backdoor for other 
types I guess.

John.