First of all, a bit on what assertions are for. Consider the following quotes from Alexandrescu:

Quote:One important thing about assertions is that they generate code in debug mode only (when the NDEBUG macro is not defined), so they are in a sense "free." This allows you to test for truths that seem so obvious that it would be a waste of cycles to verify them. But cycles are not wasted in release mode, so you have the psychological comfort to insert assertions liberally. ... There is an effective litmus test to differentiate the cases in which you need to use assert and when you need to use genuine error checking: you use error checking for things that could happen, even very improbably. You use assert only for things that you truly believe cannot possibly happen under any circumstances. An assertion that fails always signals a design or a programmer error — not a user error.

So, in a perfectly correct program (ha!), an assert will never trigger, debug or release. Now, it seems to me that there's absolutely no reason to disable asserts in your release build. The one and only time it would make sense to do so is if you're using asserts in tight performance critical code, and in that case it might be useful to have a seperate macro that is removed from the build. That aside, though, why remove the asserts? Most asserts are little more than a compare and a branch if the assert fails (and the branch should be predicted correctly after a hit or two). An assert is a condition that you believe can never happen. If it does happen, it doesn't matter whether it's a debug or release build. The only difference is that in the release build, you might not find out until it's much too late -- if you find out at all. So, why should we bother dropping the asserts at all? The performance impact is laughable unless your assert frequency is really very dense (like, an assert for every 5-10 lines of code or something). They check important conditions that in the best case will never trigger anyway, and in reality will probably trigger every so often. Consider that Solaris and Windows both ship with assertions enabled in the kernel. Several Windows BSODs, such as the "Driver IRQL NOT LESS THAN OR EQUAL TO" BSOD, are actually assertions in the kernel triggering. Things that were never supposed to be possible, except that they went and happened anyway. I believe UT 2k4 also has assertions enabled when it ships, but I'm not quite sure (a few friends say they've seen it assert on occasion). Removing asserts just seems like a good way to mask bugs, particularly those that might only appear in release mode.

In code that I've seen, asserts check to make sure that the current state/data is valid, but doesn't do anything if it isn't. Error checking code, on the other hand, does have a course of action to take if things are bad.

So with an assert, if you left it in for release mode, it would simply crash the program anyway. But the user would possibly get a message box saying so, using language that would only mean something useful to the developer. Might as well let it crash (since it's going to anyway), rather than cost a wee little bit of processing time to gain absolutely no worthwhile functionality.

If you've added release-mode functionality (such as gracefully handling an error), then it's no longer an assert, it's healthy error checking.

I'm using SC_ASSERT macro in some very speed important functions, ie. RenderText - IMHO it's obvious that in such situations tests should be ommited in release builds. However, there are many places in my code, that are subject to user actions, and sometimes, under very rare circumstances, they may produce bugs.

But they're so low level and they appear in so many places, that it would be really annoying to write specialized code for each one, so I developed special assert version - SC_VERIFY - which isn't removed from release build. This way, when sth bad happens, program will immediately crash - but IMHO it's acceptable in those rare cases, and IMHO - it's much better than leaving user with application with undefined behaviour (should we call it wild application, just like wild pointer? [wink])

I know that's called bad programming habit... but I don't want to spend > 30% of my time writing code which will greacefully handle errors... especially in an engine which's eventually's going to be replaced with new one.

Quote:Original post by ace_lovegrove
asserts are compiled out in Release builds anyways.

And I'm saying they shouldn't be.

Quote:
It sounds like you're talking about an error logging system, which is something completely different.

I never mentioned logging. An assert is an unrecoverable condition, and calling more code could exacerbate the problem. Imagine if you tried to run the assert data through your logging class, which itself has asserts. If one of those triggers, you're re-entrant and potentially in serious trouble. The only thing you can do is to abort(). Asserts are not error handling. Asserts are not graceful. Leaving asserts enabled in a release build is not a method of keeping your app from going tail up. What they are is a way of catching the mistake at the point of occurrence and making a note of that point, so that when your user complains, you know exactly where the error happened.

Quote:
So with an assert, if you left it in for release mode, it would simply crash the program anyway.

In the case that an assert condition does fire, we can assume that something has gone seriously wrong. Wrong enough that it is almost given that even if we don't crash immediately, we're going to do so very soon. So given that we are going to crash no matter what, we have two options. Either we can show the user something like this friendly little dialog:

Or we can output recoverable debug information (in this case, condition/line/file) and abort(). Notice that this involves writing your own assert, that is a little more clear than the normal library assert. Does the message mean anything to the user? Of course not. But if they can email you the output of the failure, you have some starting place for fixing the bug. If you get the "Complain to MS" dialog, how are you supposed to debug it? Where would you even start?

Quote:Original post by Koshmaar
I'm using SC_ASSERT macro in some very speed important functions, ie. RenderText - IMHO it's obvious that in such situations tests should be ommited in release builds. However, there are many places in my code, that are subject to user actions, and sometimes, under very rare circumstances, they may produce bugs.

But they're so low level and they appear in so many places, that it would be really annoying to write specialized code for each one, so I developed special assert version - SC_VERIFY - which isn't removed from release build. This way, when sth bad happens, program will immediately crash - but IMHO it's acceptable in those rare cases, and IMHO - it's much better than leaving user with application with undefined behaviour (should we call it wild application, just like wild pointer? [wink])

I do concede that there are performance critical sections of code that can benefit from removal of asserts, which is why I think using two macros is a good idea. I have the normal assert, which isn't removed, and a "fast assert", which is removed from the release build. I'd just use SC_VERIFY a lot more than SC_ASSERT.

Quote:
One reason to remove asserts in release code is that they can be replaced with something telling the compiler 'this will not happen' which can enable more optimization. The command in VS to do this is __assume ( http://search.microsoft.com/search/results.aspx?qu=__assume&View=msdn&st=b&c=0&s=1&swc=0 )
The idea is that in debug, assert() will report the problem and exit, while in release assert() turns into __assume() so the compiler makes assumptions about what is and isn't possible.

That's interesting, to say the least. But it strikes me as highly dangerous to do. Now, not only have you removed the assertion, but you've potentially changed the behavior of the code and the way the optimizer looks at the code. Maybe you'll gain a few cycles, but there's a risk of making debugging next to impossible, because any bugs that arise (particularly bugs in the compiler) will be pretty much impossible to ever track down and identify.