Usage of '_HAS_CPP0X' macro in Visual C++ compiler

Take a scenario where we are coding in Microsoft's Visual Studio VC++ 16.0 compiler
(which supports many of the C++11 features). We want to take advantage of these new features and at the same time the code should not break with older VC++ versions (which has no C++11 support).
This tip shows a possible way of doing it.

==========================================

It's simple.

Starting from Visual Studio's VC++ 16.0 version compiler, we have a macro '_HAS_CPP0X', which can be utilized for this purpose. Here are a few examples:

Comments and Discussions

In example 1, the only purpose that your #ifdef serves, is proving to a reviewer that you know of this language feature. The old style variant does exactly the same, so there is no point in writing out a second variant

In example 2, the point of the language feature, as you even state in your comment, is to let the compiler figure out the actual type. Yet, you did figure out the type yourself to be able to write the old style variant. Now, why did you write the first variant again?

Example 3 is almost the same as 2: You use auto to safe yourself some typing, yet you type several lines more to satisfy the needs of older compilers. Why would you write both versions when you have to write the old style variant anyway?

While in principle I agree, I doubt a client will force you to use different compiler versions in your team. The problem may come up however when the code development is distributed over several different teams: some of the new language features can introduce real improvements (e. g. the performance gain from using move semantics), and if another team that relies on your code doesn't have a compiler that can interpret that, using this macro would be good.

That said, Maximilien has a point here: all of your examples are just about looking nicer or introducing type-safety, but none provide real benefits to the compiled code. If you have to add the pre-C++0x code anyway, then I see no reason why you should 'uglify' your code with a macro - there is no real benefit, or the benefit of providing the more typesafe new version is nixed by wrapping it in an ugly macro together with the old style code.

In my opinion, if you still need to use older compiler that do not support new language features, DO NOT use the new language features and mix'n'match code and write ugly pre-processor that will make the code harder to read, write and debug.

I am very much in-line with this opinion, life without pre-processors in code is like heaven. But the harsh real time scenarios may give us no option but to use them, to cater various clients, whose compiler we cannot enforce or decide. I myself had nightmares managing code with heavy pre-processors, but just in case our project/product demands them, a tip like this may be useful.
Thanks Max, for sharing your opinion.