Re: failure due to compiler?

jgllgher@maths.tcd.ie says...
)>However, as expressions in C++ (and Eiffel) may have side effects, turning
)>assertion checking off may alter the behaviour of the program. One Eiffel
)>user I know claims to have experienced this perplexing behaviour. His
)>program worked as expected until he turned assertion checking off!


Dave Gillett <davidg@genmagic.com> wrote:
) The particular home-grown flavour of assertion-checking macro that I like
)has the "feature" of deliberately evaluating the tested expression *twice*.
)Code that relies on side-effects of such evaluation typically breaks while
)I'm still building debug versions.


Yes, that is a common flaw in <assert.h> implementations. DEC shipped
such a defective <assert.h> until I complained. Here is one which
I believe works. I typed it in just now, from a file which does work.
But I may have made a little typo. The __VAL__ __STR__ thing is a
standard trick used with the preprocessor to evaluate strings. Note that
the predicate is evaluated exactly once.


------------------------------------


#ifdef assert


#undef assert


#endif


#ifdef NDEBUG


#define assert(x) ((void)0)


#else


#define __ASSERT(x) ((void)(fputs("assertion failed: "),fputs(x,stderr),abort(),0)
#define __STR__(x) __VAL__(x)
#define __VAL__(x) #x
#define assert(x) ((x)?(void)0:__ASSERT(__FILE__ ":" __STR__(__LINE__) ": " #x))


#endif


------------------------------------


Mike
--
--

Return to the comp.compilers page.
Search the comp.compilers archives again.