Re: [boost] patches for embedded VC4

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 
> compilers
> also suffer the same problems
> - there is a line that generates an error anyways should you try to 
> compile
> 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 
> sure.
> Is there a tendency to uniformly use BOOST_WORKAROUND? If so, and since 
> I'm
> 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 
> I
> really understand what it does. Removing it breaks compilation, I don't 
> know
> 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 
important!).

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

John.