On 09/26/2013 06:41 PM, Peter Dimov wrote:
One general note about these changes. This:
#if defined( _MSC_VER ) && _MSC_VER >= 1310
doesn't mean "compiler is MS VC++ 7.1". It means "compiler claims to support MSVC 7.1's features."
From the point of view of the source code, those are the same.
Does that make sense? The source code uses features which MSVC 7.1 has, and assumes not to need to use ifdefs guarding such code. That is also true for new source code. People writing new source code are not going to check if it worked with all compilers pretending to be MSVC 7.1 (but not actually MSVC 7.1) and wrap it in an ifdef. We bumped the compiler requirement so that they don't have to do that. If another compiler reports that it has the features of MSVC 7.1, then that is truth, and the source code should not assume it is false.
Many Windows compilers define _MSC_VER for compatibility.
I'm not positive that the removal of the _MSC_VER >= part would break something nowadays, but if it does, this would be why. I'd have left these alone; it's not clear what purpose removing the check is intended to serve, apart from breaking code.
* Removal of near-duplicate code * Removal of obsolete workarounds (pulling in dependencies), * Removal of noise in git grep output (so you can see if a feature/define is actually used, or if it is only used inside an obsolete ifdef. git grep does not know about ifdefs) * Making the code look more like normal c++ (eg revisions 85957 and 85958), which makes reading/contributing easier. * Making it easier to move code around for modularization. ie, the purpose is the same purpose as justified the compiler requirement bump.
Actual MSVC-specific code is guarded by BOOST_MSVC and not _MSC_VER.
Only if written correctly, which is not always the case. See revision 85932, which specifically references MSVC warnings. This is moot anyway because of the above. Thanks, Steve.