Boost logo

Boost :

From: Jason Shirk (jasonsh_at_[hidden])
Date: 2001-08-31 21:15:56

I have a few comments, especially considering my experience with 3
different versions of VC++ (VC6, VC7, and my ongoing work in developing

Some parts of BOOST will not compile out of the box with new versions of

This is true for VC7 (even after correcting _MSC_VER in boost\config.h.)
There was at least 1 compilation error due to a more conforming STL.

This will also be true for VC7.1. (I have already made corrections
where BOOST_MSVC was used and perhaps another macro would have been

Simply put, some workarounds under BOOST_MSVC weren't written expecting
a conforming compiler from Microsoft. It's usually trivial to fix, but
it might not work either way with a new version of the compiler.

How about using #error instead? The BOOST user is made very aware they
are entering uncharted territory.

Of course, since VC has the greatest number of workarounds and I'm the
one fixing the compiler bugs, I could suggest assuming they'll all be
fixed in VC7.1. After all, I already have all regression tests passing
in BOOST 1.20.2 with all workarounds disabled. I've just moved on to
1.24.0 to see what bugs the new libraries have exposed.

Jason Shirk
VC++ Compiler Team

-----Original Message-----
From: David Abrahams [mailto:david.abrahams_at_[hidden]]
Sent: Friday, August 31, 2001 5:45 PM
To: boost_at_[hidden]
Subject: Re: [boost] Review: Config system

Aleksey makes some excellent points. On the other hand it is really
for developers who can handle the issues if they don't have to crawl
all of their bug workarounds and disable them just to see how well a new
compiler works. The solution seems obvious to me: we specify a
symbol which, when #defined, makes the appropriate assumption for
developers... shall we say, BOOST_DEVELOPER?


----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 31, 2001 6:28 PM
Subject: RE: [boost] Review: Config system

> Jens Maurer wrote:
> > On a different topic discussed here, unknown compiler versions
> > should be assumed to be fully compliant. If they aren't,
> > people will complain here, and we will know thusly that a new
> > version of some compiler has appeared and we can make appropriate
> > corrections.
> Being a real-world _user_ of boost (as opposite to a developer) I
> disagree. Using of boost libraries in your project is supposed to help
> in your every-day professional life, not to make it harder. Switching
to a
> new version of the compiler and getting _your own_ code to compile and
> is painful enough without being forced to deal with a sudden break of
> party libraries' code, even (and especially) if one these libraries is
> "boost". Although fortunately it's not a case for our team, I know
> people in other companies have invested a considerable amount of
> get their managers to allow them to use boost libraries in the
> code, (validly) promising that it will boost (NPI) their productivity.
> don't think that the "people will complain and we'll fix it" attitude
> something that these users would appreciate ("What??! You said it'll
> day, and it already took 3!! Some boost libraries don't compile, and
> have no idea why, and you're waiting till they will fix it?? I knew
> whole idea of using this open-source stuff in production code won't
> anything better than this!.."), and I think we should care about our
> In most real-world situations "optimistic" config scheme will force
you to
> deal with the whole "boost config" issue right away, as if it was the
> important thing in porting your project, and certainly it isn't. And
> that a new version of the compiler is indeed fully complaint and you'd
> the whole world of a new boost libraries' functionality available to
> Does it solve any of your today's porting problems? No! Could it solve
> of your tomorrow (post-porting) problems? Not likely. Could it help
you to
> solve the problems you'll be approaching in a week - may be, but
> I will be much more willing to spend time on the issue when _I_, a
> decide to do it, not somebody else.
> Aleksey
> Info: Unsubscribe:
> Your use of Yahoo! Groups is subject to

Info: Unsubscribe:

Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at