Re: [boost] [config] Using SD-6 macros

Subject: Re: [boost] [config] Using SD-6 macros
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-13 13:39:41

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