4 ms·
Why do you think the compiler with optimizations will remove the assertion? The compiler will realise that: assert(assert(line != NULL && longest != NULL
by CJefferson 15y ago
Why do you think the compiler with optimizations will remove the assertion?
The compiler will realise that:
assert(assert(line != NULL && longest != NULL && "memory error");
Is equivalent to:
assert(line != NULL && longest != NULL);
But there doesn't seem anything wrong with that.
- tptacek 15y agoProduction code is supposed to define away the assertions. It is an actual error to manage important program state with asserts. (That doesn't make these particular asserts an error).
- scott_s 15y agoIn support of tptacek's comment, an abbreviate version of what's in assert.h on my OSX system: #ifdef NDEBUG #define assert(e) ((void)0) #else #define assert(e) \ ((void) ((e) ? 0 : __assert (#e, __FILE__, __LINE__))) #define __assert(e, file, line) \ ((void)printf ("%s:%u: failed assertion `%s'\n", file, line, e), abort()) So, if NDEBUG ("no debug") is defined, which it is if optimizations are turned on, asserts become a no-op.
- zedshaw 15y agoIn the earlier chapters they setup a Makefile with full debugging on so these don't get removed. It's mostly just for this one exercise, and in the rest of the book they use a set of debug macros I wrote: http://c.learncodethehardway.org/book/learn-c-the-hard-waych21.html#x26-10500021 http://c.learncodethehardway.org/book/learn-c-the-hard-waych...