[boost] Re: compiling random on msvc 6

From: Csaba Szepesvari (cszepes_at_[hidden])
Date: 2003-05-20 02:18:32

Dear Guillaume,

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

you missed half of my point:
I meant to add BOOST_NO_LIMITS to the config part that deals with MSVC.

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

I am not that much disappointed at all:)))

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

actually this is (almost) what I have done.
I made a limits header that just calls up boost limits and defines
BOOST_NO_LIMITS and put it on the path such that whenever the user includes
<limits> she will include my file.
This what I do regularly to "fix" MSVC's problems.
I did not want to suggest this in the hope of you suggesting a better
alternative. E.g. maybe the boost limits should also be put in the boost
namespace and libararies should use it from there? Another "solution" along
this line could be to have a macro defined to either "boost" or "std"
depending on whether the limits should come from boost or std (for compilers
that have a good limits).

I htink for MSVC users it is quite a suprise that a library won't compile
after downloading and installing it!
They will get soon disappointed, a few will ever try to fix things manually
and they will rather not use boost (it's the users' choice, however, I'd
like to see people usnig boost).
Therefore I still think it would be important to have the library compile
after ti has been properly installed.

One solution could be to add some documentation of these problems, however,
still this won't be as good as having the libraries compiling out of box.

- Csaba