Re: [boost] [config] defining __has_extension in suffix.hpp?

Subject: Re: [boost] [config] defining __has_extension in suffix.hpp?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-22 10:52:09

On 22 Jan 2015 at 8:56, John Maddock wrote:

> > It's useful to have
> >
> > #ifndef __has_feature
> > #define __has_feature(x) 0
> > #endif
> >
> > #ifndef __has_extension
> > #define __has_extension __has_feature
> > #endif
> >
> > in suffix.hpp so that one can then use __has_extension(foo) everywhere
> > without fear. Otherwise, even
> >
> > #if defined(__clang__) && defined(__has_extension) && __has_extension(foo)
> >
> > is a preprocessor error when __has_extension is not defined (which it
> > isn't when not on Clang.)

I'd be opposed to that because the draft before SG10 allows patterns 
of using __has_extension which cannot be emulated reasonably in 
current compilers.

Much safer is to use the #ifdef __cpp_rtti type method of detecting 
features.

> Good point.
> 
> However, aren't those reserved symbols?  If we're being pedantic.... John.

https://github.com/ned14/Boost.BindLib/blob/master/include/cpp_feature
.h provides a header file which makes the SG10 feature macros 
standard across all the major compilers, including fixing up any 
compiler version specific abberations.

I would view this emulation of SG10 on older compilers as safe and 
reasonable. We emulate new compiler stuff on older compilers all the 
time.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/