int getNumb()
{
int x(0);
cout << "Enter a prime number below 8" << endl;
cin >> x;
return x;
}
int main()
{
int b = getNumb();
bool prime(false);
if (2 == b) prime = true;
elseif (3 == b) prime = true;
elseif (5 == b) prime = true;
elseif (7 == b) prime = true;
if(prime) cout << "Yeah baby!" << endl;
else cout << "Nope, not a prime!" << endl;
}
Just for the record because I haven't been here to reply to the whole on which side of the equals thing, to explain why I don't think that teaching people to put assignment one way round and comparison the other way round is a good idea, is because it's enforcing an incorrect principle. It is teaching people that when you put the constant on the left, it is comparison and when you put the constant on the right, it is assignment. This leads to people not only not understanding other people's code, if the other people have written it in a way that reads naturally (if x equals 3 sounds a lot more natural than if 3 equals x), but also makes people more liable to make mistakes such as the following in their own code. This will lead people to think that if(2 = b) is not an error, but is a form of comparison (constant on the left) and that if( b == 2) is an error because it is assignment (constant on the right) in an if. I also think it is plain wrong and intellectually dishonest to teach someone that it works one way, when it in fact works another way because if it doesn't work like that in absolutely all situations, eventually it'll cause a problem. And yes I know that people do it quite a lot and I'm fairly used to seeing it, but that doesn't mean I think it's right or okay. Rant over.
How should one write the code if both x and y are, say, non-const strings? Perhaps: if( const_cast< const std::string& >(x) == y ) ) { std::cout << "this is truly great code\n" ; } ?
Compilers issue a warning if the result of an assignment is used as a condition.
Turn warnings on; and pay attention to them; and one won't have to carry the baggage of remembering a whole lot of specially made "rules", one for for each special case.
1 2 3 4 5 6
int main()
{
int i = 7 ;
if( i = 3 ) return 1 ;
}
clang version 3.6.0 (tags/RELEASE_360/final 235480)
main.cpp:5:11: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
if( i = 3 ) return 1 ;
~~^~~
main.cpp:5:11: note: place parentheses around the assignment to silence this warning
if( i = 3 ) return 1 ;
^
( )
main.cpp:5:11: note: use '==' to turn this assignment into an equality comparison
if( i = 3 ) return 1 ;
^
==
1 warning generated.
g++ (GCC) 5.2.0
main.cpp: In function 'int main()':
main.cpp:5:15: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if( i = 3 ) return 1 ;
^
That's exactly what I was saying. It doesn't matter which way round it is, and I know that both ways work, I was pointing out that they don't have to be the way round that is taught to people as a simplification because I already knew that people teach that. I just personally prefer writing things in a way which is natural to say and as such I wrote it that way round while making the implicit point that both ways work.
edit: My standpoint is that either way works, and as such you should use whichever way is easiest to read, and in my opinion that is "x equals 1" not "1 equals x".