On 09/26/2013 07:13 PM, Peter Dimov wrote:
Stephen Kelly wrote:
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.
I don't understand.
We bumped the compiler requirements for MSVC. We did not bump the compiler requirements for all other compilers that define _MSC_VER.
Perhaps some of them define it to 1200 or 1300. Not emulating MSVC 7.1 features is not a reason to disqualify a compiler.
Why not? I think it is. If a compiler claims it only supports MSVC6 features (1200), then all use of MSVC > 6 features need to be wrapped in ifdefs, and I can revert everything I've committed so far, right? I guess I don't understand your position.
* Removal of near-duplicate code * Removal of obsolete workarounds (pulling in dependencies),
These do not apply to the cases I have in mind, which use _MSC_VER properly and not incorrectly, and in which the only change is from
#if defined( _MSC_VER ) && _MSC_VER >= ...
to
#if defined( _MSC_VER )
Nothing is removed, nothing is obsolete, nothing is simplified. I see no upside here.
Ok, I see your logic here. Nothing is removed, except, in this case, part of an #if logic. The code block inside remains. However, I don't understand your position: I don't understand why such _MSC_VER usage should be put back in. Maybe if you can get concrete and point out a compiler in config/compiler/* that could have a problem with the above kind _MSC_VER removal, then I might understand. However, if such a compiler is ancient itself, it makes sense to bump the version of that one too for the same reasons as before. Are you saying that you think such _MSC_VER usage should never be removed? Thanks, Steve.