Re: The MSVC enum compile-time constant workaround

From: tdr_s_at_[hidden]
Date: 2000-11-28 12:23:12

Hi, David

> A colleague of mine was recently playing around with STLPort's 
<limits>
> (actually stl/_limits.[ch]) trying to get things like is_signed to 
act as
> compile-time constants, when he discovered something which was (to 
my mind
> at least) quite surprising: MSVC will treat static const bool 
members as
> compile-time constants (at least under most conditions), even 
though it
> won't let you define them in the class body. 

Really?

// MSVC6SP4, STLPort4.0
template<class T>
struct Y {
 static const bool b;
};

template<class T>
const bool Y<T>::b = true;

template<class T>
void f(T)
{
 enum {v = Y<T>::b};
};

int main()
{
 f<int>(0); // C2057: expected constant expression
}

Some small changes to make things more interesting:

int main()
{
 Y<int>::b;
 f<int>(0); // OK.
}

More small changes:

template<class T>
void g(T)
{
 Y<T>::b;
 f(T());
}

int main()
{
 f<int>(0); // still C2057
 g<int>(0); // OK.
}

Funny, isn't it? The same trick seems to work with 
std::numeric_limits. The "apply level of indirection" principle 
strikes again.
May be that is the case your co-worker have found, but I think is 
unacceptable as a general solution.

> One reason I was surprised is
> that boost headers traditionally have used enums for this purpose. 
Moreover,
> the original Dinkum library (I don't have their updated library) 
does the
> same thing. It seems to me that our code would be better/more 
portable if we
> actually used static const XXX (i.e. whatever is called-for by the
> specification) rather than enums where possible. On the other hand, 
this
> raises the question of why numeric_limits<T>::is_signed is not a
> compile-time constant on STLPort/MSVC. Anyone have insight into 
this?
> 

I don't like it at all. Please, leave it as it is. 
The code *is* "more portable" now, although not "better" than the 
standard conforming solution. IMHO.

Todor