|
-
May 2nd, 2003, 02:15 AM
#1
assert function?
my question is about the assert() with
the following code:
#include "stdafx.h"
#include <iostream>
#include <string>
#include <algorithm>
#include <conio.h>
#include <set>
#include <assert.h>
typedef set<int> intSet;
int main(int argc, char* argv[])
{
intSet::_Pairib pib;
for (int i=0;i<1000;i++)
//assert( s1.insert(ID("xie",i)).second );
{
pib=s1.insert(ID("xie",i));
assert(pib.second);
}
..................
getch();
return 0;
}
it works OK!
but why i cant used the assert statement?
i think it's equal to the statements in the brace!
Victory
-
May 2nd, 2003, 02:52 AM
#2
Should be the same
Victory,
The compressed single line should give the same functionality as the expanded two lines. I would put the single line in braces for clarity.
Sincerely, Chris.
Code:
#include <iostream>
#include <string>
#include <algorithm>
#include <conio.h>
#include <set>
#include <cassert>
using namespace std;
typedef set<int> intSet;
intSet s1;
#define ID(a, b) 3
int main(int argc, char* argv[])
{
intSet::_Pairib pib;
for(int i = 0; i < 1000; i++)
{
assert( s1.insert(ID("xie",i)).second );
// pib = s1.insert(ID("xie",i));
// assert(pib.second);
}
return 1;
}
You're gonna go blind staring into that box all day.
-
May 2nd, 2003, 03:43 AM
#3
Except, of course, that when you compile for release mode, the expression in the assert statement will not get executed.
The two versions are not equivalent, and the single-statement version will lead to problems. Never put code with side-effects into an assert, only examine data.
Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
-- Sutter and Alexandrescu, C++ Coding Standards
Programs must be written for people to read, and only incidentally for machines to execute.
-- Harold Abelson and Gerald Jay Sussman
The cheapest, fastest and most reliable components of a computer system are those that aren't there.
-- Gordon Bell
-
May 2nd, 2003, 03:53 AM
#4
Assert yourself
Oh yeah,
I guess I had forgotten that assert code might not even get compiled under most conditions. This wouldn't work very well...
Thanks for that key reminder Graham.
Maybe it would be better to store second.pib in an intermediate variable and assert the variable.
Sincerely, Chris.
You're gonna go blind staring into that box all day.
-
May 2nd, 2003, 04:47 AM
#5
Of course, up to this point, I've refrained from wondering why on earth this code is reliant on a detail of one particular STL implementation. _Pairib is not part of the standard interface to std::set (the leading underscore is a dead giveaway) and you have to wonder why any piece of code would need to bother with it.
Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
-- Sutter and Alexandrescu, C++ Coding Standards
Programs must be written for people to read, and only incidentally for machines to execute.
-- Harold Abelson and Gerald Jay Sussman
The cheapest, fastest and most reliable components of a computer system are those that aren't there.
-- Gordon Bell
-
May 2nd, 2003, 08:39 PM
#6
Graham,Thank you for your advice
Originally posted by Graham
Never put code with side-effects into an assert, only examine data.
--·çÖ®ÐÐ
Victory
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|