Well assert is a macro that expands to if statement .
if the test value is zero assert prints the message to stderr:

if the test fails :
test , filename , line linenum is printed .
linenum is the line where the macro is used

well it depends on a persons usage that were exactly he has to use.
if u want to check some no (which might be a passwd) then use assert function . cuz if it fails the program is aborted.
but u want to perform conventional check then its prudent to use the if statements .

The important difference with assert() is that it doesn't affect production (release build) code. So all those checks don't affect performance, and as the code is debugged by then, you don't need them right? (yeah right).
For debugging I find assert() much better than exit(0) as it leaves the debugger active for a good old poke about.

ah good idea with asser() instead of exit(0), I always wish that it didn't exit (even though I told it to exit !? haha) for exactly that reason.

Thanks for the comments.

Well correct me if i am wrong .
asser macro aborts from the program not exits . there is a subtle difference btw them . the former i guess exits without performing any task . but the latter i guess has a safer exit.


well if u want to abstain ur self from exit i guess u can turn ur code something like this


i guess this should work

>Is there a reason that I shouldn't just do this in the first place?
It depends on your debugging needs. If the assertion is absolutely critical for the application to continue, and the information from a failed assert is sufficient, by all means use assert. On the other hand, if it's not a fatal error, you can usually log/trace and continue on. On the third hand, a lot of people replace the standard assert with their own macro that provides more helpful information.

Also remember that assert is meant to check code integrity. You're saying "This should always be true, and I'm writing code based on that assumption. If the assumption is false, the code is broken and this assert is there to keep the bug from making it to release". If the assertion fails, it's a logic bug that needs to be fixed.

I'd wager that instead of asserting that a and b will never be equal, you should be testing this as a case at runtime and producing a suitable diagnostic (ie. return value, setting errno, etc...). Otherwise, I'd immediately ask you how you know that a and b will never be equal. Are you generating those values? Do you have an explicit runtime check surrounding each call to this function?

Your example smells funny, and that makes your question suspect as well.

The real function is

as you can see, it doesn't make sense to get the average distance of two vectors of correspondences with different lengths! So this should indeed be handled with an assert, while some things may not.

Narue: What did you mean by "log/trace"?

Dave

>So this should indeed be handled with an assert
Once again it depends. If you have absolute control over the size of both vectors in the code, then an assertion is warranted because a mismatch is a logic error. If you don't have control over the size (it's based on user input, for example) then an assertion is a mistake. In the latter case I would prefer throwing an exception.

>Narue: What did you mean by "log/trace"?
Don't scuttle the boat if you can fix the problem. The majority of errors aren't fatal, and recovery is an option. But silent recovery may or may not be a good idea. In cases where you want to notify users of problems without throwing something in their face, you can write to an execution or error log that can be viewed at a later time.

The cleanest and nicest explanation, one could hope for!

Assert is a C++ macro and when the compiler comes across assert, it replaces the assert call with the instructions to evaluate an expression + the instructions to exit the program if the expression returned false ...

e.g.: assert(1>2); will exit the program because 1 isn't greater than 2 ...