RE: [boost] py_cpp does not like STLport (STLport bug revealed)

From: Petr Kocmid (pkocmid_at_[hidden])
Date: 2000-11-09 23:03:39

> > Well, I am going to hack py.cpp to BOOST_NO_LIMITS for myself
> That's the wrong fix. I think you need to make the following change in
> boost/cast.hpp:
> // Move to config.hpp?
> -#if defined(__SGI_STL_PORT) && __SGI_STL_PORT <= 0x400 &&
> __STL_STATIC_CONST_INIT_BUG
> +#if defined(__SGI_STL_PORT) && __SGI_STL_PORT <= 0x410 &&
> __STL_STATIC_CONST_INIT_BUG
> // STLPort 4.0 doesn't define the static constants in numeric_limits<> so
> that they
> // can be used at compile time if the compiler bug indicated by
> Boris had previously promised to change <limits> for the next release so
> that things like is_signed could be used as compile-time constants with
> MSVC, but apparently that hasn't been done (yet).

Oh, thats exactly what I needed, very thanks! 

> > question arises: What's the benefit of having boost::numeric_cast<>
> > at all inside py.cpp, not counting the joy of maintaining twice the
> > same thing?
> What on earth are you talking about? I haven't copied the source of
> boost::numeric_cast<>!?!

I am sorry I expressed myself ambigously. What I really mean is why
at all are two branches in py.cpp, conditioned by BOOST_NO_LIMITS,
one using boost::numeric_cast<> and another using static_cast<>.
I feel having only the second one would be simply more efficient.
I understand the numeric_cast is more safe, but introduces unnecessary
overhead. Perhaps, conversion checking mechanism should
be selectable. Seeing a real-time engine, feeding tons of ints into it's
scripting doing try/catch the bad numeric cast which never happens
makes me less happy...

Petr Kocmid
pkocmid_at_[hidden]