[meghprkh]

Why would they not do something like?

  + #if !(defined __GLIBC_COMPILER_SUPPORTS_ATTRIBUTES__)
  - #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__)
  # define __attribute__(xyz)     /* Ignore */
  #endif

(or probably a more fine grained for each attribute they try to use)

Considering such checks are fairly conventional in downstream C++ libraries based on compilers (for example checking OS platform or compiler, e.g. [Boost.Config](https://www.boost.org/doc/libs/latest/libs/config/). Modern C++ even went ahead and standardized this somewhat https://en.cppreference.com/cpp/utility/feature_test )

[ventana]

I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle.

It's probably just natural for software developers (myself included), whenever only FooZoid v5 supports frobnicate(), say "#ifdef FOOZOID_V5" and go back to your business, rather than introducing "FROBNICATE_SUPPORTED".

Also, when you try to ask for a feature flag in the code review, people will throw YAGNI at you, and they might be not wrong, at least for the first few years. After that, it's a costly refactor.

[fc417fc802]

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.

[MereInterest]

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.

[0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...

[fc417fc802]

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.

[account42]

The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).

[fc417fc802]

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