On May 10, 2013, at 8:25 PM, Richard Smith <richard_at_[hidden]> wrote:

> On Tue, May 7, 2013 at 1:00 PM, John Spicer <jhs_at_[hidden]> wrote:
> I'm not personally fond of that direction.
>
> At least for EDG, and I suspect others, the set of feature supported is going to depend on command-line options, which would mean that we'd have to define one set of macros (or something) to allow the <features> header to define another set. It also makes it more likely that you could have a <features> file that doesn't actually match what the compiler does.
>
> Since our names are reserved identifier, an implementation can predefine them and provide a <features> which does nothing.
>
> This allows feature test macros to be provided (a) with no compiler changes, (b) retroactively for an implementation which was released prior to our recommendations (provide a <features> which checks the compiler and version, and use -D__cpp_lib_header_features), and (c) with (essentially) zero cost for programs which do not use the macros. This also happens to be standardizing existing practice ;-)
>
> That said, I agree with Clark that quantifying the cost in (c) would be useful. I have informally heard that this cost is measurable (especially for things like configure scripts which build a large number of tiny programs), but I've never seen numbers.

I don't have a problem with requiring an include of <features> in order to access feature macros.

I would hope, however, that compiler vendors would either recognize that header and then predefine the appropriate macros or have the file contain something like

        #pragma define_feature_macros

What I would not like to see, which is actually what existing practice is, is a file that said something like:

        #if defined(__GNUC__) && __GNUC__ >= <something> && __GNUC_MINOR__ >= <something>
          #define __cpp_has_xxx <something>
          #define __cpp_has_xxx <something>
        #elif defined(_MSC_VER) && ...
          #define __cpp_has_xxx <something>
          #define __cpp_has_xxx <something>
        ... etc ...

So, I agree that this has the advantage of providing a bridge that can be used with implementations released prior to specifying the feature macros, and also has the advantage of having zero cost unless they are used.

But I think to most effectively address the issue, compiler support is required.

To quote an example that Clark provided:

#ifndef __USE_RVALUE_REFERENCES
  #if (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 3) || \
      _MSC_VER >= 1600
    #if __EDG_VERSION__ > 0
      #define __USE_RVALUE_REFERENCES (__EDG_VERSION__ >= 410)
    #else
      #define __USE_RVALUE_REFERENCES 1
    #endif
  #elif __clang__
    #define __USE_RVALUE_REFERENCES __has_feature(cxx_rvalue_references)
  #else
    #define __USE_RVALUE_REFERENCES 0
  #endif
#endif


My hope is that our recommendations will eliminate the need for heuristics and rely on a definitive answer from the compiler.

John.

>
> John.
>
> On May 7, 2013, at 3:17 PM, Richard Smith <richard_at_[hidden]> wrote:
>
> > Hi,
> >
> > Has any thought been given to putting the feature-test macros into an implementation-supplied header, instead of predefining them? This would allow us to remove the cost associated with predefining these macros, for translation units which don't need them. Instead, we could supply a single predefined macro indicating whether the header is available, and user code would write something like:
> >
> > #ifdef __cpp_lib_header_features
> > #include <features>
> > #endif
> >
> > #ifdef __cpp_relaxed_constexpr
> > constexpr
> > #endif
> > size_t strlen(const char *p) { /* ... */ }
> >
> > ... and so on.
> > _______________________________________________
> > Features mailing list
> > Features_at_[hidden]
> > http://www.open-std.org/mailman/listinfo/features
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features