Is there a version of assert() that doesn't exit?

[Seebs]

True, but we weren't discussing /replacing/ __builtin_expect().
We were discussing whether, in that macro, __builtin_expect() did something
essential for the operation of the macro.

If someone asserts that f(x) is "doing something essential", I would say
it has to differ in some way from x.

-s

 

[Jens Thoms Toerring]

[...] You need to recode the header something
like this (not tested, etc.):

------- my_assert.h -----------------------------------

#if ! defined MY_ASSERT_HEADER
#define MY_ASSERT_HEADER

int my_assert_print( const char * /* expression */,
const char * /* filename */,
int /* line */ );

#endif /* ! MY_ASSERT__HEADER */

#undef my_assert

#ifdef NDEBUG
#define my_assert( expression ) do { } while ( 0 )
#else
#define my_assert( expression ) \
( ( void ) ( ( expression ) ? \
0 : my_assert_print( #expression, __FILE__, __LINE__ ) ) )
#endif

Note that this wouldn't work as a substitute for the Standard
assert() macro, which must expand to a void expression rather than
to a statement. For example, one can write

if ( assert(i < N), array != 42 ) ...

Under NDEBUG, the corresponding line using my_assert() wouldn't compile.

Thank you. I don't remember why I did it that way, probably
out of some bad habit.

#ifdef NDEBUG
#define my_assert( expression ) ( ( void ) ( 0 ) )

does the job much better;-)
Best regards, Jens

 

[Nobody]

True, but we weren't discussing /replacing/ __builtin_expect().

He didn't replace it; he eliminated it. He didn't eliminate its argument,
which /is/ important for the functioning of that macro.

 

[Jorgen Grahn]

.

Which solution is appropriate will, of course, depend on your individual
requirements (eg. are these asserts purely for debugging, or will they
be retained in production code? The latter is bad practice for asserts
but may not be for soft asserts).

That statement ("asserts in production code is bad practice") is
controversial. Many think it's perfectly alright to leave them enabled.

(I don't want to start *that* flamewar again, but I had to point it out
since the OP seemed to be new to this assert business.)

/Jorgen

 

[Edward]

That statement ("asserts in production code is bad practice") is
controversial. Many think it's perfectly alright to leave them enabled.

(I don't want to start *that* flamewar again, but I had to point it out
since the OP seemed to be new to this assert business.)

/Jorgen

Ok then, s/the latter is bad practice/the latter is often argued to be
bad practice/.
Thanks for pointing that out; I wasn't aware there was any controversy.
-Edward