Re: [boost] compiling random on msvc 6

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-20 03:39:33

On Tue, 20 May 2003, Csaba Szepesvari wrote:

[snip]

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

No, I didn't miss your point. What I wanted to explain is that it's not a
problem specific to MSVC, it's a more general problem. And so there is no
reason to add BOOST_NO_LIMITS to the config part that deals with MSVC.

First, the user doesn't have to use the standard library shipped with her
particular version of the compiler. She may want to use another library
(STLport for example), or a more recent version of the default library,
etc.

Second (and it's why I was giving the example of the one shipped with
GCC), not all standard libraries will accept BOOST_NO_LIMITS to be defined
without complaining. And consequently a lot of user projects may get
broken by such a change to MSVC configuration.

So the solution is not as easy as just defining BOOST_NO_LIMITS in some
headers.

[snip]

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

I think it's a better solution.

> 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

Is it such a surprise? If you take a look at the regression logs for Boost
( http://boost.sourceforge.net/regression-logs/ ), you will see that 33%
of the tests complain when the compiler is MSVC 6, and 19% with MSVC 7.
Users should be aware that Boost libraries are really complex; and
consequently some compilers and or standard libraries may not be compliant
enough to correctly compile them.

> 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

I'd like to see people using compliant compilers and standard libraries,
so that there is no more problem if a Boost library is correctly written.
:-)

> 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

Regards,

Guillaume