Thank you Jonathan. I cannot overstress the importance of emphasizing that the primary use case is to enable more aggressive adoption of new standard features in code bases that for whatever reason must support older compilers for a while, and that the intent is to keep the feature tests there only until the last old compiler goes away and then remove the tests. That is the best argument I have heard to address reasonable concerns that they lead to language fracturing, and this is exactly the kind of “how they are intended to be used” guidance that has not been clearly documented that Gaby in particular has been asking for. So please do clearly articulate that, perhaps in the next revision or somewhere prominent.
Thank you again, Herb > On Oct 7, 2017, at 5:29 AM, Jonathan Wakely <[email protected]> wrote: > > > >> On 6 October 2017 at 01:19, Herb Sutter <[email protected]> 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). >
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
