On Friday 24 April 2015 13:32:36 John Maddock wrote:
Folks,
I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58).
Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14).
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. 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?