Can i do something like this:
Code:#define check( obj ) \ ...elided... \ #define check
Can i do something like this:
Code:#define check( obj ) \ ...elided... \ #define check
Out of curiosity, 6tr6tr, have you read Stroustrup's answer to the FAQ: So, what's wrong with using macros? ?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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
Among the reasons mentioned here for keeping an assert in the code is this:
FWIWAnother reason for keeping asserts in the ship version of an embedded product is that turning the asserts off will change the timing characteristics of the program. On a desktop application, this rarely leads to a different end result. In real-time applications, removing the asserts may lead to misbehavior that did not arise before-and the assertions will not be in place to detect the situation. It's also worth bearing in mind that on the desktop, more speed is always better, while on embedded products, extra speed is often not an advantage, once you meet your hard real-time targets.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Same. Difference. (I was only asking if you kept the assert; not for the particulars of the implementation. I don't care if it 'abort's of not.)No, I keep the custom __assert__ function.
Still... I think I'm in love. First person I ever met that has the good sense to keep an assert in release builds.
Soma
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'm not sure if this is sarcasm, but assuming it isn't, I'm one of the followers of that school of thought as well.
Having the asserts get compiled in only for debug, encourages you to do final testing in debug configuration. This is, of course, a tragically wrong thing to do. When you test in debug, then recompile for release, and don't repeat all of your testing again, what you have essentially done is released a completely untested binary.
You might attempt to argue that if the assert didn't get triggered in debug, it wouldn't be triggered in release, but that naively ignores the fact that bug behavior can change dramatically when moving to release mode.
So, you either have to give up the concept of asserts altogether, or you have to leave them in the release build. I choose the second option...
Nope. Not sarcasm. (Well, not entirely. ^_^)I'm not sure if this is sarcasm, but assuming it isn't, I'm one of the followers of that school of thought as well.
Beyond what you, and the other guys, have pointed out, I've just rarely seen the things used in ways that they can safely be removed from release builds. (That is to say, I usually see 'std::assert' used in code that has side effects that must remain in release builds for the code to perform correctly.)
Naturally, being me, I try to avoid them in favor of compile-time firewalls, but when I do use my form of assert, which either throws a complex exception that supports "appended" types and information or 'abort's outright, the only difference between debug and release builds is where the debug information is presented by default--debug console versus a file dump.
Soma
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.
To be honest, its a widely under used debugging tool that truly does protect against tiny errors that keep us up at night.Code:void drawObject(object *x) { assert(x); assert(x->image); // etc. ... }
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.