Boost logo

Boost :

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
> (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.


// 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()
 f<int>(0); // OK.

More small changes:

template<class T>
void g(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.
> 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,
> raises the question of why numeric_limits<T>::is_signed is not a
> compile-time constant on STLPort/MSVC. Anyone have insight into

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.


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