Re: [boost] compiling random on msvc 6

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-19 16:06:08

On Mon, 19 May 2003, Csaba Szepesvari wrote:

> trying to compile the minimal sample code below I get:
>
>  'std::numeric_limits<`template-parameter258'>::is_integer' : illegal use of
> this type as an expression
>         c:\dev\include\boost\random\uniform_01.hpp(95) : see reference to
> class template instantiation
> 'boost::uniform_01<UniformRandomNumberGenerator,RealType>' being compiled
>
> The problem is that although random.hpp includes limits.hpp from boost and
> limits.hpp
> includes boost/detail/limits.hpp only if BOOST_NO_LIMITS is defined.
> Wouldn't it be good to add BOOST_NO_LIMITS to either
> - config
> - the random library

It would be really bad to do such a thing. And you already guessed the
reason: if the user includes <limits>, the compiler will complain.
However, you missed a point, you said "inadvertantly". It's not true, the
user may not have the choice: a lot of libraries rely on <limits>.

For example, if I try to compile your code snippet with my favorite
compiler (GGC, and it has a bad <limits> implementation) and the macro
BOOST_NO_LIMITS, the compiler will complain. Why? Because <iostream>
includes <limits>.

So let's just suppose I remove the include <iostream> so that there is no
<limits>. The program won't display anything anymore, too bad; but maybe
it will finally work. Unfortunately, it still doesn't compile. And the
reason has not really changed: the Random library includes <iostream>
which itself includes <limits>.

So, with any of your hacks (BOOST_NO_LIMITS or _ASWORKAROUND), the Random
library won't work anymore because it relies on <limits>. Sorry to
disappoint you, but I don't think it's the proper way to fix things.

In fact, there is a solution: there could be a specially crafted library
able to disable all the standard <limits> (it requires knowing for each
standard library and each version of those library what it is the name of
the macro excluding the inclusion of <limits> and its subheaders) and the
user would have to ensure it is the first library the compiler will ever
include. It would work (it is something I commonly use to get the Boost
<limits> version in place of the standard header) but it is not as easy as
just defining BOOST_NO_LIMTS.

Regards,

Guillaume

> I understand that the user should (maybe) decide about using
> BOOST_NO_LIMITS, however,
> the user also wants random.hpp compiling "out-of-box".
> Maybe, should add BOOST_NO_LIMITS_ASWORKAROUND
> and limits.hpp should also check this and if defined include
> boost/detail/limits.hpp.
> Well, this could cause other problems if the user inadvertantly(:)) includes
> <limits> in the same compilation unit.
> But then at least the user would face the real problem and could decide what
> to do.
> (Maybe some documentation of this would also be useful e.g. documenting what
> libs workarounds that incluences the files the user can include.
>
>
> - Csaba
>
> ------------- SAMPLE CODE ---------------------------
> //#define BOOST_NO_LIMITS
>
> #include <boost/config.hpp>
> #include <boost/random.hpp>
> #include <iostream>
> int main()
> {
>   using namespace boost;
>
>   minstd_rand mm;
>   int x = mm();
>   std::cout << x;
>   return 0;
> }