the reason is that "=" is an assignment operand,
and "==" is a test of equality operand.
Why are we taught "if( variable == constant )"?
Sneftel is right,
The programmer should be testing aspects of his/her code for correctness under different situations, seasoned programmers very rarely have this issue, and it usualy comes from the user of languages that use a single '=' as both conditional equality and assignment.
So, call me an elitist, but I belive you should be good enough in your programming skill to not make mistakes like that, and even when you do, be able to identify them, through normal program debugging practice.
The compiler already holds my hand far too much.
just my 2 cents.
The programmer should be testing aspects of his/her code for correctness under different situations, seasoned programmers very rarely have this issue, and it usualy comes from the user of languages that use a single '=' as both conditional equality and assignment.
So, call me an elitist, but I belive you should be good enough in your programming skill to not make mistakes like that, and even when you do, be able to identify them, through normal program debugging practice.
The compiler already holds my hand far too much.
just my 2 cents.
Quote:Original post by FeralOfEclecticWizard
Use syntax highlighting to color '=' differently from '==' ? Works pretty well actually...
Clever!
Quote:Original post by FrunyYou know how to do it without Visual Assist?Quote:Original post by FeralOfEclecticWizardClever!
Use syntax highlighting to color '=' differently from '==' ? Works pretty well actually...
This is a problem, but usually only for beginners. I programmed in BASIC for several years before learning C++, and in BASIC you don't have == you just have = and the compiler knows what to do with it. So when I switched to C++ I had this problem a lot. But I was able to get used to it after a very short time, and I can't remember the last time I made that mistake. I think it's good if the compiler issues a warning when assignments are made within conditions.
Quote:Original post by Sneftel
(except for the fact that many compilers will warn about such assignment to a constant within a conditional, rendering this trick redundant)
That was the only case I was talking about really, I'll fully agree that in the general case the compiler can't tell which one the programmer was intending. However all the C or C++ compilers don't even flag the special case of assignment in a conditional - although the most recent one I used was probably VS6, has this simple check been added since then?
The problem that you're pointing out should be considered nothing short of a defect of C++. Modern languages don't allow implicit conversions from integers to bools, so the type of error you show here isn't even possible. In C#, "if (x = 5)" won't compile, because the if statement wants a boolean value, and you're giving it an integer.
Quote:Original post by OrangyTangI know VS7 catches it with warnings turned all the way up.... don't recall with VS6. I'd check GCC, but my shell server has decided to be grumpy today.
However all the C or C++ compilers don't even flag the special case of assignment in a conditional - although the most recent one I used was probably VS6, has this simple check been added since then?
I've never seen this as much of a problem in my own code, but if you really wanted to be explicit you could always:
#define EQUALTO ==
Although its debatable whether using the preprocessor in this way is good practice. In the end you should do what you feel comfortable with, unless you work in a team, in which case you should stick to accepted practices.
#define EQUALTO ==
Although its debatable whether using the preprocessor in this way is good practice. In the end you should do what you feel comfortable with, unless you work in a team, in which case you should stick to accepted practices.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement