On 6/13/2015 11:45 AM, Niall Douglas wrote:
On 13 Jun 2015 at 12:22, Andrey Semashev wrote:
What difference could it possibly make ? You test if a macro is defined and if it is not you try something else. If it is you have your answer.
For a compiler that does not support SD-6 you would end up with "the compiler does not support C++" with this approach. :) Seriously, you do have to know when to check those macros, if you want to know the actual capabilities of the compiler.
APIBind enforces a consistent and correct set of SD-6 language feature macros on all versions of clang, GCC and MSVC using https://github.com/ned14/Boost.APIBind/blob/master/include/cpp_feature .h. It then uses those SD-6 macros to create a partial emulation of Boost Config in https://github.com/ned14/Boost.APIBind/blob/master/include/boost/confi g.hpp.
I can see SD-6 only as a helper tool for libraries like Boost.Config and not as an alternative. We had various version and feature checks in Boost.Config for years, it worked wonderfully and I don't see why it would break for the existing compilers we support. Future compilers may add features that are currently missing, and we will have to update Boost.Config accordingly, whether the compilers use SD-6, misuse it or not use it at all.
Also, if I remember correctly an unadvertised feature of Boost.Config is that it is completely standalone capable. You can include it as a git submodule to your project and use it for compiler detection without any requirement on the rest of Boost.
What does config being standalone capable have to do with SD-6 ? I do not recall that SD-6 has anything to do with using other Boost libraries, do you ?
I think SD-6 macros are relevant for detecting very new C++ language features, apart from that their usefulness is limited. I find in particular the library feature detection macros to be almost useless in the real world as what you actually do in practice is target a certain minimum standard library featureset, so if the code compiles it does if not then it doesn't. You don't write #ifdef code for multiple standard library versions usually as it's just easiest to swap in Boost if you can't rely on your standard library i.e. you either mandate a Boost dependency or a minimum standard library featureset, you don't have your code self adjust to library availability as you would language feature availability (usually).