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.