Comment by 20k
3 days ago
That's not what the C/C++ spec says people can rely on with assert/NDEBUG. Like don't get me wrong, you can do what you want, but you can and will break code in ways that introduce memory unsafety with this approach
3 days ago
That's not what the C/C++ spec says people can rely on with assert/NDEBUG. Like don't get me wrong, you can do what you want, but you can and will break code in ways that introduce memory unsafety with this approach
I dunno, if a library author is toggling flags that control the nature of the end user's build that seems like tempting fate to me. How do you justify such interference?
To my mind the extent of the contract is that if the user has set NDEBUG then you can assume that assert will be a noop. I don't think you as a library author can make any assumptions about what happens if you set the flag yourself.
You absolutely can make assumptions about what happens if you set the flag, and the spec guarantees that you can!
There's no difference between the flag being set/unset by your build system, and #define-ing or #undef-ing the symbol in code