if comparison: value first

  • Thread starter Thread starter Santi
  • Start date Start date
S

Santi

I see in some code, I don´t remember now if it is c# or c++, that the
when they perform a comparison they use the value first and then the
variable, like:

if( null == variable ){}

Is there an explanation for this or is it the same as doing the usual
variable == value?
 
Is there an explanation for this or is it the same as doing the usual
variable == value?
Click to expand...

In C++ people use it to avoid writing

if ( variable = value )

by mistake. That's perfectly valid C++ code (though modern compilers
generate a warning) where you get an assignment to variable instead of
a comparison.

Since you can't make that mistake in C#, it doesn't matter which order
you write things in.



Mattias
 
Hi Santi,

It is the same as doing (variable == value). No reason for doing it other
than company policy I suppose. I certainly find it harder to read than
the regular variable == value, and value == variable is rarely found in
any code.
 
Santi said:
I see in some code, I don´t remember now if it is c# or c++, that the
when they perform a comparison they use the value first and then the
variable, like:

if( null == variable ){}

Is there an explanation for this or is it the same as doing the usual
variable == value?
Click to expand...

The end result is the same, however there is a reason.

In C++, if statements operated on numbers(0 being false and not-zero being
true, most of the time), therefore it was possible to accidentally do

if (variable = 5)
{
}

and have that if statement to always evaluate to true. Doing 5 = variable
causes the compiler to complain that you cannot assign to a value, thus
catching that error and avoiding a bug.

Its less important in C#, as you can only cause this error with boolean
types themselves.
 
In C++ people use it to avoid writing
if ( variable = value )

by mistake. That's perfectly valid C++ code (though modern compilers
generate a warning) where you get an assignment to variable instead of
a comparison.

Since you can't make that mistake in C#, it doesn't matter which order
you write things in.
Click to expand...

No. It still works with boolean types. Something like

if (bFlag = true)

is valid C# code and doesn't even generate a warning if true is replace with
a non-constant expression.
 
cody said:
No. It still works with boolean types. Something like

if (bFlag = true)

is valid C# code and doesn't even generate a warning if true is
replace with a non-constant expression.
Click to expand...

so use:
if (bFlag) ...

or (instead of "if (bFlag == false)"):
if (! bFlag) ...

Hans Kesting
 
Santi said:
I see in some code, I don´t remember now if it is c# or c++, that the
when they perform a comparison they use the value first and then the
variable, like:

if( null == variable ){}

Is there an explanation for this or is it the same as doing the usual
variable == value?
Click to expand...

A lot of C-based languages allow variable assignment in an if statement (one =
instead of two), which is a failure of the language. So, the idea is if you
swap the order of the operands, you will get a compiler warning if you swap the
order of the operands. In this case if you forget one =, then you will get a
compiler warning *if* you were intending to compare to a _constant_. Then
entire premise breaks down if you are intending on comparing two variables.

As I said, it is a complete failure of the language. A language should _not_
permit raw unadorned assignments within the conditional. What should be in
place is that assignments, when necessary, would have to be performed
parenthetically, such as:

if ((variable = null) == null)

and
if (variable = null) // compiler error, assignment in conditional

Then it becomes instantly obvious by looking at the code what is intended, and
the assignment in conditional warning mystery goes away.
 
A lot of C-based languages allow variable assignment in an if statement (one =
instead of two), which is a failure of the language.
Click to expand...

For if()s I'll agree. But for while() statements, it's a very useful
and valuable construct. It allows you to write things like:

while ( (x=getvalue()) != 0)
{
// do stuff
}

instead of the more clumsy:

x = getvalue()
while(x !=0)
{
// do stuff
x = getvalue();
}

as you would have in every other high level language. I'd suggest that this
was one of the main reasons for C's early popularity.

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
James Curran said:
For if()s I'll agree. But for while() statements, it's a very useful
and valuable construct. It allows you to write things like:
Click to expand...

I throughly disagree, especially when you are working with error codes

T x;
if ((x = getvalue()) == 0)
{
print("ERROR!");
}

with pretty much the same argument you had for while, the other method is as
bad in some peoples eyes as this is to others.

Also, from a pure design standpoint, modifying if to not support assignments
is simply not going to happen. C languages are expression based, if takes an
expression. Assignment cannot be changed into a non-expression withough
removing the functionality of while and a number of other things.

Also, changing if alone would not do any good, it would simply save things
in one particular cirucmstance.

consider that

if ( 1 == (y = (( x =10) + 5 )))
{
}

and
if (1 == (y == ((x = 10) + 5)))
{

}


or

bool b = v = true;
and
bool b = v == true;

exhibits the same mistake, even though the error occurs within a grouped
expression, it is still a logic error with the same root cause...someone
used the wrong operator.

Another cute one is that disallowing assingments removes the capacity to do

if (x == y = 5)
{

}

without extraneous which, again, is a completely valid expression.
Illadvised, perhaps, but valid and consistent.

The only real way to fix this is to change the assignment or comparison
operator so that they are not so similar or to throw expression based
semantics totally out the window. I imagine that both would be unattractive
to most people who use C based languages, as that would cost us our beloved
++ and -- operators.
 
if (bFlag = true)
so use:
if (bFlag) ...

or (instead of "if (bFlag == false)"):
if (! bFlag) ...
Click to expand...

In expressions like

if (GetThingy() || !(GetValue() && MyValue))

The bang symbol is most likely to be overlooked thats why most times I don't
use it .
 
Daniel O'Connell said:
I thoroughly disagree, especially when you are working with error codes

T x;
if ((x = getvalue()) == 0)
{
print("ERROR!");
}
Click to expand...

I'm not sure what you are getting at here. Re-writing that without the
assignment in the if() gives us:

T x;
x = getvalue();
if (x==0)
{
print("ERROR!");
}

Which should generate precisely the same object code as your version.
That is not the case with the while() code I presented before. There, the
version with the assignment inside the while() is more efficient (space-wise
at least; it should be a wash speed-wide) then the version without the
assignment.

One could argue one is stylistically better than the other, but
programming style wasn't even on the radar when C was created. Writing the
smallest, fastest code in 1970s era machine was the only concern.
cannot be changed into a >> non-expression without removing the
functionality of while and a number of other things.

Yes, but you're looking at it from the wrong way. Assignment is an
expression, because they wanted to do assignments inside a while() (to make
writing a C program easier), and wanted to use the same expressions
evaluator for while statement as elsewhere (to make writing a C compiler
easier).

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
I'm not sure what you are getting at here. Re-writing that without the
assignment in the if() gives us:

T x;
x = getvalue();
if (x==0)
{
print("ERROR!");
}

Which should generate precisely the same object code as your version.
That is not the case with the while() code I presented before. There, the
version with the assignment inside the while() is more efficient
(space-wise
at least; it should be a wash speed-wide) then the version without the
assignment.

One could argue one is stylistically better than the other, but
programming style wasn't even on the radar when C was created. Writing
the
smallest, fastest code in 1970s era machine was the only concern.
Click to expand...

Yes, but I wasn't arguing the reasons why C included it, simply a reason why
removing it would be a greater pain than anything else. It is a touch late
to be concerned about explaining Cs reasons, they just don't matter that
much anymore.

Also, your original argument said "clumsy", not inefficent. You seemed to be
talking style quite clearly to me.
cannot be changed into a >> non-expression without removing the
functionality of while and a number of other things.

Yes, but you're looking at it from the wrong way. Assignment is an
expression, because they wanted to do assignments inside a while() (to
make
writing a C program easier), and wanted to use the same expressions
evaluator for while statement as elsewhere (to make writing a C compiler
easier).
Click to expand...

I don't think I'm looking at it from the wrong way at all. If C had chosen
to disallow assignment as an expression I would probably think it a mistake.

I don't consider languages that special case everything to be terribly well
designed. If the expressions if, while, for, and method calls can accept are
different, you are basically turning what is a simple, logical structure
into a horrible mess. Could you imagine the learning process?

Yes, you can use assignments in while and for and even lock, but not if, of
course unless you put it in parentheses.
No, you cannot use increments in if statements.
No, no conditional expressions in the first or third part of for.

It just doesn't make sense. Never will. C may have made its choices for
speed, but it certainly doesn't mean that those ideals should be thrown away
simply because speed isn't any issue(many performance based ones are already
gone in C# and java, like arrays are pointers). The end result is a language
that is exceedingly simple to parse and quite flexible to write in. And,
above all, a language that isn't hacked together and nearly impossible to
ever be comfortable with, which, IMHO, the changes proposed would do(or
atleast start the process of doing so).

It is a failing to many languages fall into, protecting from errors at the
cost of capacity to get work done.
 
Daniel said:
I throughly disagree, especially when you are working with error codes

T x;
if ((x = getvalue()) == 0)
{
print("ERROR!");
}

with pretty much the same argument you had for while, the other method is as
bad in some peoples eyes as this is to others.

Also, from a pure design standpoint, modifying if to not support assignments
is simply not going to happen. C languages are expression based, if takes an
expression. Assignment cannot be changed into a non-expression withough
removing the functionality of while and a number of other things.
Click to expand...

I didn't say no assignments in an if/while/whatever, just no (what I'm calling)
_RAW_ assignments meaning that if you are doing an assignment in a conditional,
stick it in parentheses:

if ((x = getvalue()) == 0) // compiles

if (x = getvalue()) // doesn't compile: no assignment in conditional

if (x = getvalue() == 0) // doesn't compile: no assignment in conditional

if ((x = getvalue())) // doesn't compile: assignment w/o conditional test

if (x == 0) // compiles

same applies to while()

This way, you get _meaningful_ error messages, don't have to play the
reverse-the-order-of-operands-in-an-if-conditional game, and all existing code
will either already comply or easily be converted to the new syntax.

Remember, this thread is about _why_ some switch the compare operands in an if,
such as if (true == x), which is bass-ackwards with respect to the way that we
verbally describe the condition.
 
J. Jones said:
I didn't say no assignments in an if/while/whatever, just no (what I'm
calling) _RAW_ assignments meaning that if you are doing an assignment in
a conditional, stick it in parentheses:

if ((x = getvalue())) // doesn't compile: assignment w/o conditional test
Click to expand...

Why must if have a conditional? What if getvalue and x are booleans? Must if
(x == true) be used as well? It doesn't even solve the entire problem, it
just solves the conditional in if problem(as I mentioned, this identical
problem can occur anywhere, even in method parameters or while).

To my mind, forcing a conditional to be combined with an assignment is
almost certainly the wrong thing to do. It complicates the language without
offering a significant enough boost in productivity or usability(usability
will actually drop, I think, producitivy could lose a little as well).

As it stands, in C#, there is only a very small circumstance where this can
happen, that is with booleans. The compiler could stand to dump out
warnings, but disallowing it in the language would be a horrid waste.
Consistency should rule over everything but the most egregious of potential
errors, and this is not one of them(the switch statement wasn't either, but
they got this one right atleast).

This is not language failure, its compiler implementation failure(failing to
issue a proper warning) or programmer failure. A programmer should be quite
capable of writing the correct statement(really, how often do you mess this
one up?).
 
Daniel O'Connell [C# MVP] wrote:
This is not language failure, its compiler implementation failure(failing to
issue a proper warning) or programmer failure. A programmer should be quite
capable of writing the correct statement(really, how often do you mess this
one up?).
Click to expand...

Never, right?

The question should be: how many times have I messed it up and _don't_ know
about it.
 
J. Jones said:
Daniel O'Connell [C# MVP] wrote:
This is not language failure, its compiler implementation failure(failing
to issue a proper warning) or programmer failure. A programmer should be
quite capable of writing the correct statement(really, how often do you
mess this one up?).
Click to expand...

Never, right?

The question should be: how many times have I messed it up and _don't_
know about it.
Click to expand...

Since the language barely allows it, it doesn't happen daily, or even
monthly.

However, I (and others) cover my code pretty well, and someone has certainly
caught the this mistake. I've done it, I'll admit. However, I find that only
a tiny portion of my mistakes with this particular error occurs in if
statements. I see it as commonly in while statements and in general code
where I was simply comparing two objects. Changing the semantics of if
wouldn't help any of that, my code would still be wrong and my language less
flexible.

As I said, the only foolproof way to do this is to change the langauge to
more a statement based one, or change the assignment and equality operators
to be different, := and == comes to mind.
 
Back
Top