From: John Maddock (john_at_[hidden])
Date: 2005-03-10 11:27:22
> If you look at the patch, you will see that most changes are explained by
> removing '#if _MSC_VER==1200' in favour of '#if _MSC_VER<1300'. At first
> glance those are not really equivalent, but there are some considerations
> that will make it sensible:
> - if (which I doubt will ever happen) there come any updates to those
> compilers they will still have version numbers < 1300
> - if VC6 and similar suffer a defect, chances are good that older
> also suffer the same problems
> - there is a line that generates an error anyways should you try to
> boost code with <1200, older compilers are simply not supported.
I think those changes all look OK, if you have cvs access, I don't see why
you shouldn't commit them
> I noticed that some places use BOOST_WORKAROUND while others use _MSC_VER
> directly. For #pragma once that makes still sense, since you don't want to
> first include the header for the macro, but in other cases I'm not so
> Is there a tendency to uniformly use BOOST_WORKAROUND? If so, and since
> touching a lot of those checks already, should I replace those?
Not sure, some of those _MSC_VER checks are actually for Intel compilers,
probably best to leave it alone for now.
> The change in boost/detail/lwm_win32.hpp is something where I don't claim
> really understand what it does. Removing it breaks compilation, I don't
> how to test if it really works.
Talk to Peter Dimov: post a message with a subject line he'll notice (one
that mentions the file by name).
If the code links OK then I guess it should be alright: the workaround
relies on _InterlockedExchange being a compiler intrinsic.
> The changes in boost/function/function_template.hpp are something that
> shouldn't break anything, except if the brackets where in fact an
> undocumented workaround for some other bug....
They are: I believe these are a Borland specific workaround, a better
approach, and one which should work for both compilers is to use:
typedef typename ct_if< ::boost::is_void<R>::value,
For these cases (note the leading :: and the space after the <, both are
> Working on this, I noticed that some files I checked out of CVS were write
> protected!? Is that just my setup, intentional or by accident? I didn't
> investigate further.
It happens to me as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk