On 6 October 2017 at 01:19, Herb Sutter <herb.sutter@gmail.com> wrote:

> why you would not use that alternative in all cases if you want your code to be portable across compilers

Because he wants to use the new better features on those compilers that support them.

This is important because it’s the only clear motivating use case I’ve heard so far for feature test macros: To encourage aggressive new C++ feature adoption for third-party libraries that do not control their customers’ compiler choice, so that they can adopt a new C++ feature on the compilers that support it, while still working on downlevel (down to C++98) compilers they also have to support.

Not just third-party libraries but any code that's built with more than one compiler. A company's first-party code might get built with different compilers for machines running a different OS, and for example might have a more efficient implementation of something on GNU/Linux compared to Solaris. A standard library implementation might want to enable different features depending on which compiler it's used with, for example libstdc++ defines deduction guides conditionally on __cpp_deduction_guides, so it can still be used with older Clang releases that don't support them (arguably this is just a special case of a third-party library, but quite a special one). These are both real world examples.

Feature test macro are useful! And more useful when all compilers participate in the convention (or the ones that don't define them still need fragile compiler-specific preprocessor gunk, or the code simply assumes the worst and degrades to the old-style code for those compilers).