🚀 go-pugleaf

Take a look at assert.h : assert is a macro with one argument
Just replace the #include <assert.h> by a
dummy definition like:
#define assert(_1) /* _1 */
You can even roll your own assert (make it conditional on
a #defined DEBUG_LEVEL or so)

LotzofLuck,
Adriaan van Kessel.

In article <DEL047.BCD@rivm.nl>, A. van Kessel <imaavk> wrote:
>Take a look at assert.h : assert is a macro with one argument
>Just replace the #include <assert.h> by a
>dummy definition like:
>#define assert(_1) /* _1 */

Yep.  There's a whole can of worms here - I've seen long threads on
this subject in other newsgroups.  But if you want to keep the asserts
in the production code, by all means come up with an alternate macro
definition or some other method to deal with the error.  Unfortunately,
actaully dealing with the inconsistencies on the fly in a robust way
can be extremely difficult.
-- 
Danny Faught -- Convex -- Operating System Demolitions Specialist
"Everything is deeply intertwingled."  (Ted Nelson, _Computer Lib_)

In article <42o1ns$qdk@itchy.adacel.com.au>, owen@itchy.adacel.com.au (Owen Veenstra) writes:
> 
> I am using assertions to detect simple programming and interface 
> problems (ie valid ranges etc).  Having the program die during 
> execution at this point is therefor acceptable.
> 
> However, in the system it will be intgrated into, it is 
> unacceptable to have the module simply crash the system because 
> an assertion failed.  Therefore, assertions would be removed.

What I do is to not use the system assert at all.  I use:

	/* Logging messages.  These can be seen with Microsoft's DebugWin or WinIce. */
	/* ??? Since macros can't have varargs, LOGF does not have braces around it,
	 * which could cause a problem for nested if-else statements.
	 */
	void LogFormatMessage (char *format, ...);
	#define LOG(string)     { if (IniFileInfo.log) {        \
	                                OutputDebugString ("SM:  " string "\n"); } }
	#define LOGF            if (IniFileInfo.log)  LogFormatMessage
	
	/* Taed's ASSERT code -- with or without a return value. */
	#define NOT_REACHED 0
	#if defined(_DEBUG)
	#define ASSERT(expr)            { if (! (expr)) {       \
	                                        LOGF ("ASSERTION FAILED: \"%s\" at line %u in file \"%s\".",      \
	                                                #expr, __LINE__, __FILE__);     \
	                                        _asm { int 3 }; \
	                                        return (SM_STATUS_ASSERT_FAILURE); } }
	#else
	#define ASSERT(expr)
	#define ASSERT_VOID(expr)
	#endif

As you can see, my ASSERT pops into my debugger (this is DOS/Windows, mind you
  -- on Unix, I just use the standard assert macro), and then returns an
  error.  That way if the debugger is not running, it is OK.  I do get rid of
  the ASSERT code if it is not debugging, but you can easily fix that.

Note the clever printing of a log message if the assertion fails.  That way, I
  cover all the bases -- log file, debugger, and error value.  I work with
  partners who do not have access to my source code, and so all of those come
  in handy -- particularly if they just send me log files.

As far as my opinion on the "should one have asserts in production code", I'm
  of two minds.  As you can see, on my current project, I left them out.  On
  other projects, I've left them in.  I guess it depends on my level of
  confidence.