Comment by harry8
3 days ago
doesn't everyone write their own assert macros?
ASSERT(cond, "msg %s", str_contents); //#ifndef NDEBUG logic
ASSERT_ALWAYS( ...);
check the condition, write out the msg, maybe dump a backtrace if that works in your codebase, call abort();.
assert() is just kind of nasty, why use it?
precondition in the function sig is just "We know you don't document and nobody reads it if you do." Which is great, but not worth the control you get writing your own ASSERT_ALWAYS() and being able to s/_ALWAYS//if the performance in release matters.
> assert() is just kind of nasty, why use it?
For libraries there is some value in using the standard interface instead of inventing your own that users then have to deal with. I agree that assert() could be better though.
On the other hand, even the C++ stdlib implementations have their own assert handlers so...
I'm used to libraries being release builds so NDEBUG is defined and assert() is compiled out - in debug builds of client code. I'm not understanding what you mean by "standard interface."
What is an assert handler? Is it a debugger for the dump so you can get a backtrace and examine things that way? $ gdb ./prog core Your macro finishes by calling abort() so you have that.
The value of being able to print an arbitrary string, with whatever current variable values you like is not nothing. Printing out a backtrace (if you can with your codebase) is also really useful. Obviously your own macro will print file, line and function. assert(a == b); triggering tells you almost nothing about the failure, why the check was there, what failed etc. It really should.