Re: Math Constants - is_specialized?

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-07-24 13:31:53

on 7/19/00 5:34 PM, Paul A. Bristow at pbristow_at_[hidden] wrote:

> David Abrahams wrote
> 
> For things like is_specialized which need to be compile-time constants the
> VC6 workaround (sortof - more of a bodge - already used for numeric_limits
> by Plauger's Dinkumware Library - packaged in a macro _STCONS(ty, name, val))
> 
> is to use an enum:
> 
> enum {is_specialized = true};  // Bodge for MSVC 6
> // returns an int not a bool, so outputs
> // "math_const<long> is specialised 0"
> 
> // need to use
> //   static_cast<bool>(int_math_const<int>::is_specialized)
> // to get bool and output:
> // "math_const<long> is specialised false"
> 
> How much longer must we wait for a Standard compiler from MS???

From what I've read here and on comp.lang.c++, it seems that Microsoft's
compiler really sucks.  What's their problem, and why do a lot of people use
it?

> Daryle Walker suggested
> 
> static const bool is_specialized() { return false; }
> 
> which does correctly return the expected bool
> 
> but this is different from numeric_limits and requires a call
> 
> boost::math_const<long>::is_specialized()
> 
> instead of
> 
> boost::math_const<long>::is_specialized  // as numeric_limits
> 
> 
> I feel the is_specialized is useful, but to be different from numeric_limits
> is unacceptable.
> 
> So with regret I propose to follow the current MS limits bodge, or leave it
> out for now.
> 
> At least with a static_cast<bool> the code will always be correct and never
> need changing.
> 
> Other views or suggestions?

Whoa, I didn't suggest that!  I said:

> template <typename T>
> struct math_const
> {
> // a specific instantiation should override this to 'true'
> static bool is_specialized = false;

i.e. I had it as a compile-time constant, like you suggested.  Whoever did
the "mathConstants.hpp" file (who based it off my e-mail) changed it.  Don't
blame me.

Having it as a compile-time constant could make it capable for that meta-if
template stuff that's also going around in this list.  (I'm thinking of
taking advantage of this for an adapter class idea.)

[A few minutes pass...]

In a later e-mail, I did say:

> The point of my message was to suggest using (inline) functions to get the
> constants instead of declared static const members.  AFAIK, inline static
> const members only work for the integral types, and not the floating (which
> means that the original sample is wrong) nor user-defined types.

I meant that for the main numeric constants (in which the original
idea-holder had as static floating constants [which you can't do]), which
are dependent on the template parameter.  Any general information that never
changes type (like is_specialized) should stay as static constants, if
possible.

--