if comparison: value first

[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?
--
Santi
www.syltek.com

[Mattias Sjögren]

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

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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Morten Wennevik]

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.

--
Happy Coding!
Morten Wennevik [C# MVP]

[Daniel O'Connell [C# MVP]]

"Santi" <sa****@nospam. es> wrote in message
news:cr******** **@nsnmrro2-gest.nuria.tele fonica-data.net...

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?

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.

[cody]

> 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.

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.

[Hans Kesting]

cody wrote:

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.

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.

so use:
if (bFlag) ...

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

Hans Kesting

[J. Jones]

Santi wrote:

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?
--
Santi
www.syltek.com

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.

[James Curran]

"J. Jones" <[e-mail] m> wrote in message
news:41******** *******@networl d.com...

A lot of C-based languages allow variable assignment in an if statement (one = instead of two), which is a failure of the language.

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

[Daniel O'Connell [C# MVP]]

"James Curran" <Ja*********@mv ps.org> wrote in message
news:%2******** *******@TK2MSFT NGP10.phx.gbl.. .

"J. Jones" <[e-mail] m> wrote in message
news:41******** *******@networl d.com...

A lot of C-based languages allow variable assignment in an if statement

(one =

instead of two), which is a failure of the language.

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:

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.

[cody]

>> if (bFlag = true)

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

so use:
if (bFlag) ...

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

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 .