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.