| | |
Why use assert?
Please support our C++ advertiser: Intel Parallel Studio Home
Thread Solved |
•
•
Join Date: Feb 2008
Posts: 629
Reputation:
Solved Threads: 46
For a while now I've been doing this when I want to check the input of a function (in this example, to make sure they are not equal).
But when the assert fails, I always find my self changing it to
Is there a reason that I shouldn't just do this in the first place?
Thanks,
Dave
C++ Syntax (Toggle Plain Text)
void foo(int a, int b) { assert(a != b); }
But when the assert fails, I always find my self changing it to
C++ Syntax (Toggle Plain Text)
void foo(int a, int b) { if(a != b) { cout << "a: " << a << " b: " << b << endl; exit(0); } }
Is there a reason that I shouldn't just do this in the first place?
Thanks,
Dave
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 .
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.
For debugging I find assert() much better than exit(0) as it leaves the debugger active for a good old poke about.
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
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
C++ Syntax (Toggle Plain Text)
int cmp (int a , int b) { return(a!=b); } and in main function if(cmp(a,b)) cout<<"both r not equal";
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.
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.
I'm here to prove you wrong.
•
•
Join Date: Feb 2008
Posts: 629
Reputation:
Solved Threads: 46
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
C++ Syntax (Toggle Plain Text)
double AverageDistance(const vector<Point> &A, const vector<Point> &B) { assert(A.size() == B.size()); double Total = 0; for(unsigned int i = 0; i < A.size(); i++) Total+= Distance(A[i], B[i]); return Total/A.size(); }
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.
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.
I'm here to prove you wrong.
•
•
•
•
>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.
Two roads diverged in a wood, and I— I took the one less traveled by, and that has made all the difference.
by Robert Frost the "The Road Not Taken"
by Robert Frost the "The Road Not Taken"
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.:
e.g.:
assert(1>2); will exit the program because 1 isn't greater than 2 ... "Never argue with idiots, they just drag you down to their level and then beat you with experience."
![]() |
Similar Threads
- Does We Really Need 'Assert' (C++)
- ASSERT failed? >.< (Windows NT / 2000 / XP)
- assert question (C++)
- php error when using invision board (PHP)
- basic fstream stuff (C++)
Other Threads in the C++ Forum
- Previous Thread: Problem with C++ in Visual Studio 2005 under VISTA
- Next Thread: error: expected unqualified-id before 'bool'
| Thread Tools | Search this Thread |
api array based beginner binary bitmap c++ c/c++ calculator char char* class classes coding compile compiler console conversion convert count data database delete desktop developer directshow dll dynamiccharacterarray email encryption error file forms fstream function functions game getline google graph homeworkhelper iamthwee ifstream input int integer java lib linkedlist linux list loop looping loops map math matrix memory multiple news node number numbertoword output parameter pointer problem program programming project proxy python random read recursion recursive reference return rpg sorting string strings struct template templates test text tree unix url vector video visual visualstudio win32 windows winsock word wordfrequency wxwidgets






