From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-02 09:51:28
----- Original Message -----
From: "John Maddock" <John_Maddock_at_[hidden]>
>
> >Maybe we should be checking BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
instead
> >of just BOOST_NO_LIMITS? It seems like we could correct for this
> VC6/STLport
> >4.0 deficiency... but then we'd have to put our limits in a different
> >namespace from std (e.g. boost/detail).
>
> I did suggest that in a previous message, but Jens was against it,
> personally I don't mind either way.
The next version of STLport will have this fix, so I don't know how critical
it is... but I expect the next version to be another beta. I think STLport
4.0 will be around for a long time.
> >#ifndef _WIN32
> >template<>
> >class numeric_limits<wchar_t>
> > : public _Integer_limits<wchar_t, INT_MIN, INT_MAX>
> >{};
> >#else
> >class numeric_limits<wchar_t>
> > : public _Integer_limits<wchar_t, 0, USHRT_MAX>
> >{};
> >#endif
> >
> >Is a test for the target OS really the right one to be doing here?
>
> What else should we do? gcc on Win32 has a "short" wchar_t, where as it's
> int sized on all other gcc platforms as far as I know.
>
> >Shouldn't we replace BOOST_STL_DECLARE_LIMITS_MEMBER with
> >BOOST_STATIC_CONSTANT?
>
> Sure, I just ran out of time, although as this is basically a gcc only
> workaround does it matter that much?
If we try to do the VC-stlport fix it is no longer a GCC-only patch. Of
course I can't force you to be more ambitious, but I don't think it's much
of a stretch from what you've already done, and it would make lots of things
better.
Regards,
Dave