4 ms·

Invariant vs unit tests aside. Doesn't this being a gcc plugin make it inherently unattractive? Wouldn't want to have to rip that code out if I wanted the code

by ghotli 4y ago

Invariant vs unit tests aside. Doesn't this being a gcc plugin make it inherently unattractive? Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain. Otherwise, seems cool if that doesn't matter / will never matter in the lifetime of the codebase

yjftsjthsd-h 4y ago
> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain. I wonder if it can be wrapped in #ifdef ?
- loeg 4y ago
  Better to define a macro that evaluates to the contract/invariants on GCC and empty on other compilers, rather than copying the ifdef/else/endif logic around to every usage.
- gavinray 4y ago
  Yeah sure, there's nothing preventing you from using "constexpr" so it's compile-time evaluated and inlined: (Please no more macros, it's 202- I mean, 2023!) static constexpr bool DEBUG = true; [[demo::invariant]] [[gnu::used]] void check_invariants() { if constexpr (!DEBUG) return; assert(top >= 0 && top <= MAX_SIZE); }
  - celrod 4y ago
    Note that `assert`s are disabled if you define the macro `NDEBUG`, e.g. https://godbolt.org/z/hMWo8KM7q https://godbolt.org/z/hMWo8KM7q CMake defines the macro in release builds: https://github.com/Kitware/CMake/blob/e1eacbe2c522a8bf9a82afb483fe395140240614/Modules/Compiler/GNU.cmake#L58-L60 https://github.com/Kitware/CMake/blob/e1eacbe2c522a8bf9a82af... Would be nice to have a non-macro solution for controlling behavior at configure time, but the `NDEBUG` macro is basically already your `DEBUG` constexpr.
msla 4y ago
> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain. I can only imagine some companies would literally never have the problem of switching to a new compiler toolchain.
balfebs 4y ago
That is a concern, but this makes invariants something the compiler can reason about more easily, since they happen at function boundaries and are distinct from regular code, unlike “vanilla” assertions.
gavinray 4y ago
> Doesn't this being a gcc plugin make it inherently unattractive? I'm the author, and even I think so. I'm more of an LLVM fan myself (though I can't not mention David Malcom's work on the GCC Static Analyzer). (Ideally it wouldn't be a plugin at all, it'd be a language feature. We got Contracts and left out the most useful contract of them all) Originally, I started it as a Clang plugin, thinking that I could also implement support for the Contracts "[[pre]]" and "[[post]]" specification on top (or at least some minimal implementation of it). This turned out to be a lot more work. If people would like to use this from Clang, even without support for regular Contracts, I will publish a compatible Clang plugin. I think at some point there was support for Contracts in Clang, maybe longer term I'll try to get them working again? (I've no experience here) https://github.com/arcosuc3m/clang-contracts https://github.com/arcosuc3m/clang-contracts This fellow wrote a whole ~200 page thesis on this just as recently as 2018, such a shame for it to go to waste =/ https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_Jose_Cabrero_Holgueras_2018.pdf?sequence=1&isAllowed=y https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_J...
loeg 4y ago
It's a reasonable concern, but you could wrap it in macros that selectively enable it only on GCC.

by ghotli 4y ago

yjftsjthsd-h 4y ago

> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain. I wonder if it can be wrapped in #ifdef ?

loeg 4y ago
Better to define a macro that evaluates to the contract/invariants on GCC and empty on other compilers, rather than copying the ifdef/else/endif logic around to every usage.
gavinray 4y ago
Yeah sure, there's nothing preventing you from using "constexpr" so it's compile-time evaluated and inlined: (Please no more macros, it's 202- I mean, 2023!) static constexpr bool DEBUG = true; [[demo::invariant]] [[gnu::used]] void check_invariants() { if constexpr (!DEBUG) return; assert(top >= 0 && top <= MAX_SIZE); }
- celrod 4y ago
  Note that `assert`s are disabled if you define the macro `NDEBUG`, e.g. https://godbolt.org/z/hMWo8KM7q https://godbolt.org/z/hMWo8KM7q CMake defines the macro in release builds: https://github.com/Kitware/CMake/blob/e1eacbe2c522a8bf9a82afb483fe395140240614/Modules/Compiler/GNU.cmake#L58-L60 https://github.com/Kitware/CMake/blob/e1eacbe2c522a8bf9a82af... Would be nice to have a non-macro solution for controlling behavior at configure time, but the `NDEBUG` macro is basically already your `DEBUG` constexpr.

msla 4y ago

> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain. I can only imagine some companies would literally never have the problem of switching to a new compiler toolchain.

balfebs 4y ago

That is a concern, but this makes invariants something the compiler can reason about more easily, since they happen at function boundaries and are distinct from regular code, unlike “vanilla” assertions.

gavinray 4y ago

> Doesn't this being a gcc plugin make it inherently unattractive? I'm the author, and even I think so. I'm more of an LLVM fan myself (though I can't not mention David Malcom's work on the GCC Static Analyzer). (Ideally it wouldn't be a plugin at all, it'd be a language feature. We got Contracts and left out the most useful contract of them all) Originally, I started it as a Clang plugin, thinking that I could also implement support for the Contracts "[[pre]]" and "[[post]]" specification on top (or at least some minimal implementation of it). This turned out to be a lot more work. If people would like to use this from Clang, even without support for regular Contracts, I will publish a compatible Clang plugin. I think at some point there was support for Contracts in Clang, maybe longer term I'll try to get them working again? (I've no experience here) https://github.com/arcosuc3m/clang-contracts https://github.com/arcosuc3m/clang-contracts This fellow wrote a whole ~200 page thesis on this just as recently as 2018, such a shame for it to go to waste =/ https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_Jose_Cabrero_Holgueras_2018.pdf?sequence=1&isAllowed=y https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_J...

loeg 4y ago

It's a reasonable concern, but you could wrap it in macros that selectively enable it only on GCC.