Thread: How overload a define macro?

Can i do something like this:

Code:

#define check( obj )      \
   ...elided...           \

#define check

Originally Posted by laserlight

Out of curiosity, 6tr6tr, have you read Stroustrup's answer to the FAQ: So, what's wrong with using macros? ?

Yep.

You can overload a macro at compile time. I do it for debug and release versions of a custom assert and a debug print macro.

Code:

void __assert__(const char * file, unsigned line, bool dump);

#ifdef DEBUG
#define DEBUG_PRT(args) std::printf args 
#define ASSERT(expr) if (!(expr)) __assert__(__FILE__, __LINE__, true); 
#else 
#define DEBUG_PRT(args)
#define ASSERT(expr) if (!(expr)) __assert__(__FILE__, __LINE__, false); 
#endif

O_O

You... you keep the assert?

Soma

Originally Posted by phantomotap

O_O

You... you keep the assert?

Soma

No, I keep the custom __assert__ function.

Code:

void __assert__(const char * file, unsigned line, bool dump)
{
   	std::fprintf(stderr, "Assertion failed at line %u in file %s\n", line, file);
   	std::fflush(NULL);
   	if (dump) std::abort();
}

I am with Dave on this one sometimes. The timing issue actually has arisen for me a time or two, but that isn't always my only justification. I am heavy into using asserts in fundamental levels of a program, i.e. memory management. I personally would rather a program die during various critical errors via assert rather than more or less write my own equivalent to assert in order to accomplish the task of aborting safely.

On the flip-side, on non-fundamental levels of a program (such as rendering to the screen) I think its best practice for it not to be compiled into a release version.

I guess now we should really consider the fact of when assert() should be used. When debugging real-time code on a pc, I do use them during development just to protect me against idiotic errors that take forever to debug. i.e.

Code:

void drawObject(object *x)
{
   assert(x);
   assert(x->image); // etc.
   ...
}

To be honest, its a widely under used debugging tool that truly does protect against tiny errors that keep us up at night.


So at this point I agree with you entirely brewbuck. Now for the part where I tip my hat to Dave's logic. assert() is handy for embedded devices as he pointed out, but not only that, its handy for security protocols too. One can make assertions about what someone is doing, and ultimately just kill the program instead of allowing a serious attack to be performed. Or in less doomsday-ish scenarios, you'd be amazed at how nice it is to get feedback from an end-user relevant to why a program is giving them trouble instead of just getting a couple emails saying "The program seems to crash very rarely, and I think it has something to do with when I open a help file."

Just some thoughts. Feel free to argue the merits of my commentary.

Requirements of high criticality code (eg developed to SIL 4 - safety critical) would not work well with asserts(). For those types of development it is generally necessary to define requirements (preconditions, postconditions, etc) of code, and then ensure through analysis and design that the code IS NOT invoked in any way that does not meet the requirements. Using a run-time mechanism to detect violated requirements is insufficient to satisfy such demands.

Consider software that monitors human vital signs and controls a respirator: the set of conditions when that software can terminate safely are very small (eg when medical staff consider it appropriate to take the patient off the respirator).

Originally Posted by matsp

you need full checking that the pointer is valid before attempting to use it [or make sure pointers are never invalid, which of course is a better approach].

In high criticality code, the more usual approach is to ensure pointers are never invalid in the first place. In practice, that means a few constraints (eg dynamic memory allocation is rarely used in a high critical application, except in a clearly defined startup or initialisation phase, reinitialisation virtually never occurs, etc) as that makes it easier to analyse the code and gather evidence that unwanted behaviours do not occur (or are acceptably unlikely to occur).

Clearly that requires a lot more analysis (both of functions, and how the system as a whole uses them). But a side-effect is that assertions are generally unneeded: the system design prevents low level assertions from failing anyway.