RE: [boost] Review: Config system

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
VC7.1.)

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

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

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
useful
for developers who can handle the issues if they don't have to crawl
through
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
preprocessor
symbol which, when #defined, makes the appropriate assumption for
developers... shall we say, BOOST_DEVELOPER?

-Dave

----- 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
strongly
> disagree. Using of boost libraries in your project is supposed to help
you
> 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
work
> is painful enough without being forced to deal with a sudden break of
3rd
> party libraries' code, even (and especially) if one these libraries is
> "boost". Although fortunately it's not a case for our team, I know
that
many
> people in other companies have invested a considerable amount of
efforts
to
> get their managers to allow them to use boost libraries in the
production
> code, (validly) promising that it will boost (NPI) their productivity.
I
> don't think that the "people will complain and we'll fix it" attitude
is
> something that these users would appreciate ("What??! You said it'll
take
1
> day, and it already took 3!! Some boost libraries don't compile, and
you
> have no idea why, and you're waiting till they will fix it?? I knew
that
the
> whole idea of using this open-source stuff in production code won't
lead
to
> anything better than this!.."), and I think we should care about our
users.
> 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
most
> important thing in porting your project, and certainly it isn't. And
suppose
> that a new version of the compiler is indeed fully complaint and you'd
get
> the whole world of a new boost libraries' functionality available to
you.
> Does it solve any of your today's porting problems? No! Could it solve
any
> 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
personally
> I will be much more willing to spend time on the issue when _I_, a
user,
> decide to do it, not somebody else.
>
>
> Aleksey
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>

Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/