Re: [boost] [config] Rethinking feature macros?

Subject: Re: [boost] [config] Rethinking feature macros?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-11-06 15:00:01

On 11/06/17 17:41, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
> 
>> I don't see much of a problem with the negative form. The idea is that 
>> the macros indicate compiler defects wrt. the latest standard (plus 
>> the positive form macros for non-standard features), which I think 
>> makes sense. This way the number of defined macros tend to be always 
>> low on good compilers, which is probably better than having them 
>> continuously grow over time.
> 
> This was the case ten years ago but not now. You can no longer derive 
> any quality metric by what a compiler supports. gcc 6 is not a non-good 
> compiler, it just defaults to C++14. VS 2017 15.3 is not a non-good 
> compiler, it's just not 15.5 yet. Given the new pace of the standard, 
> there will never be any longer a point at which a good compiler will be 
> macro-free, as there will always be things left to implement because 
> they were added after the compiler shipped.

I'm not saying any given compiler is good or not, and that there is (or 
should be) a macro-free compiler. I'm saying that having ~10 macros 
defined for g++-7 -std=c++17 is probably better than ~100 macros. And 
having ~10 (other) macros defined for g++-15 -std=c++22 is yet better 
than ~200.

Also, another minor point. In the user's code, the #ifdef checks can be 
viewed as workarounds for compilers not supporting a particular language 
feature. Potentially, you could strip some of the conditionally compiled 
code over time to raise the minimum bar of supported C++, thus reducing 
the maintenance cost. This could even be done with a preprocessor. Of 
course, that is not always as simple as that, but at least partially 
this can be made to work. This can be done with positive form as well, 
but I think it would be more complicated since you'd have to keep the 
code instead of removing it.