Hacker News Reader

Comment by 20k | Hacker News Reader

Blindly replacing #include <assert.h> to look up something incompatible that doesn't respect NDEBUG seems like a remarkably bad idea

View on HN

I don't see why. The user invoking the compiler should be the only one controlling NDEBUG (or its equivalent). So far the only bad idea I've run into is the occasional library author blindly importing assert.h which happily stomps all over my custom implementation.

There's a whole host of things that libraries need to be extremely conservative about touching. Assert, threads, signals, etc.

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

Reply on news.ycombinator.com