The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.
The problem with feature tests is that you then rely on the test code being correct. A typo in the feature test can erroneously be interpreted as lack of that feature.
One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actually find it.
I don't see the problem? You need to test your feature test code just like anything else. Bugs can show up anywhere after all. This is the sort of code that lives deep in a utility library and rarely if ever changes.
It's an interesting point though that the parts of a program that don't fail loudly are prone to having bugs go unnoticed.
Naturally you can also implement DOES_WHAT_I_WANT_IT_TO( foo( x ) ) as a follow on. For example I have some code that relies on specific IEEE floating point properties; rather than hope for the best I explicitly test the behavior at program initialization. I also have lots of compile time tests of the form constexpr does_what_I_want() { ... } static_assert( does_what_I_want() ).
One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actually find it.
[0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...