$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [config] Configuring for C++14 and later library features.
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-04-24 13:40:13
>> This doesn't look acceptable to me, but what to do?  The only solution I
>> can see is to simply not support these features in Boost.Config, but
>> rather rely on users needing these features checking the std detection
>> macros directly.  Which will work up until someone implements a feature
>> without defining the appropriate macro :(
>>
>> Thoughts?
> You could just define the macro based on compiler version. That could be
> backed by a test which not only checks for __cpp_lib_integer_sequence but for
> std::integer_sequence itself.
Compiler version is irrelevant, it's the std lib that matters.  I think 
for most std lib's, yes we could use existing machinery to check this, 
I'm not sure about clang/libc++ though - _LIBCPP_VERSION appears to be 
stuck at 1101 and the clang version number is notoriously unreliable.  
Any clang experts confirm this?
> PS: I thought it was enough to include any STL header (e.g. cstddef) to get
> all these macros defined. Isn't it the case? How would one test for a feature
> that is implemented in a new header?
Please see the paper linked to, but basically it suggests using 
__has_include(<name>).  Of course technically, none of this is in the 
standard, rather it's contained in an ever changing "standing document".
John.