3 ms·
Why do you do things like: assert(doSomethingThatChangesState() == 0); throughout your code? I thought the point of assert was for debugging purposes and yo
by jdmt 13y ago
Why do you do things like:
assert(doSomethingThatChangesState() == 0);
throughout your code? I thought the point of assert was for debugging purposes and you should never change program state inside the assertion.
- halayli 13y agoI prefer to fail as soon as possible. I use asserts in places where there is no good way to recover from a failed invariant.
- jdmt 13y agoFailing immediately is certainly an easy way to handle unrecoverable errors. However, it seems as though your library assumes NDEBUG is never defined. Maybe you should make your own function rather than using assert()?
- halayli 13y agoThe asserts are in the .c files. Defining NDEBUG in your program won't change anything in lthread because the library was compiled without NDEBUG defined. If you want to define NDEBUG when compiling lthread, that's up to you.
- sebcat 13y agoIf you compile assert(foo(bar) == 0); with NDEBUG, foo will never even be called. I've seen some funky bugs from this in the past, like people calling malloc inside an assertion... Works great during dev, release build has NDEBUG defined, no test coverage... You get the picture. A better idea would be to capture the return value in a var and do the assert on the var.
- halayli 13y agoYes I understand that foo() won't be called if you defined NDEBUG. But when compiling lthread, NDEBUG is not defined anywhere in the code / makefiles so it's guaranteed to be called and I want to assert the returned value.