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

Subject: Re: [boost] [config] Using SD-6 macros
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-13 11:45:09

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.

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

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/