Comment by fc417fc802
4 days ago
No, it's not. Don't do that. Someone (like me) will replace assert.h wholesale and it will not behave the way you expected. Always define your own internal macro and always provide facilities for the user to override it.
Blindly replacing #include <assert.h> to look up something incompatible that doesn't respect NDEBUG seems like a remarkably bad idea
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
2 replies →
> Always define your own internal macro and always provide facilities for the user to override it.
that kinda sounds even more insane and cumbersome
It's literally standard practice. You import assert.h unless the end user has defined mylib_assert in which case you don't import and use that instead. Failing to do this can result in all kinds of dumb problems thanks to the namespace being global.
This is totally backward. It's literally not any standard practice I have ever seen. In fact, it is an anti-practice. If you go around re-#defining standard library macros then you get what you deserve, and get no sympathy from me.
And it seems completely sensible that if I'm writing a C++ library that it's header files should include assert.h, and use assert()'s in its inline functions. And you will get no sympathy from me if you break my code by redefining the library behavior of assert().
2 replies →