On 6 October 2017 at 01:19, Herb Sutter <herb.sutter_at_[hidden]> 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).