$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.