Boost logo

Boost :

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

> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at