== Operator and operands

Question

I want to check whether a value is equal to 1. Is there any difference in the following lines of code

Evaluated value == 1

1 == evaluated value

in terms of the compiler execution

Answer 1

It's the same thing

Answer 2

In most languages it's the same thing.

People often do 1 == evaluated value because 1 is not an lvalue. Meaning that you can't accidentally do an assignment.

Example:

if(x = 6)//bug, but no compiling error
{
}

Instead you could force a compiling error instead of a bug:

if(6 = x)//compiling error
{
}

---

Now if x is not of int type, and you're using something like C++, then the user could have created an operator==(int) override which takes this question to a new meaning. The 6 == x wouldn't compile in that case but the x == 6 would.

Answer 3

No, but the latter syntax will give you a compiler error if you accidentally type

if (1 = evaluatedValue)

Note that today any decent compiler will warn you if you write

if (evaluatedValue = 1)

so it is mostly relevant for historical reasons.

Answer 4

Depends on the language.

Answer 5

if value == 1
if 1 == value

Is exactly the same, but if you accidentally do

if value = 1
if 1 = value

The first one will work while the 2nd one will produce an error.

Answer 6

They are the same. Some people prefer putting the 1 first, to void accidentally falling into the trap of typing

 evaluated value = 1

which could be painful if the value on the left hand side is assignable. This is a common "defensive" pattern in C, for instance.

Answer 7

For this and similar questions can I suggest you find out for yourself by writing a little code, running it through your compiler and viewing the emitted asembler output.

For example, for the GNU compilers, you do this with the -S flag. For the VS compilers, the most convenient route is to run your test program in the debugger and then use the assembeler debugger view.

Answer 8

Sometimes in C++ they do different things, if the evaluated value is a user type and operator== is defined. Badly.

But that's very rarely the reason anyone would choose one way around over the other: if operator== is not commutative/symmetric, including if the type of the value has a conversion from int, then you have A Problem that probably wants fixing rather than working around. Brian R. Bondy's answer, and others, are probably on the mark for why anyone worries about it in practice.

But the fact remains that even if operator== is commutative, the compiler might not do exactly the same thing in each case. It will (by definition) return the same result, but it might do things in a slightly different order, or whatever.

Answer 9

In C languages it's common to put the constant or magic number first so that if you forget one of the "=" of the equality check (==) then the compiler won't interpret this as an assignment.

In java, you cannot do an assignment within a boolean expression, and so for Java, it is irrelevant which order the equality operands are written in; The compiler should flag an error anyway.

Answer 10

In general, it hardly matters whether you use, Evaluated value == 1 OR 1 == evaluated value.

Use whichever appears more readable to you. I prefer if(Evaluated value == 1) because it looks more readable to me.

And again, I'd like to quote a well known scenario of string comparison in java. Consider a String str which you have to compare with say another string "SomeString".

str = getValueFromSomeRoutine();

Now at runtime, you are not sure if str would be NULL. So to avoid exception you'll write

if(str!=NULL)
{
   if(str.equals("SomeString")
   {
      //do stuff
    }
}

to avoid the outer null check you could just write

if ("SomeString".equals(str))
{
   //do stuff
}

Though this is less readable which again depends on the context, this saves you an extra if.

Answer 11

In Prolog or Erlang, == is written = and is a unification rather than an assignment (you're asserting that the values are equal, rather then testing that they are equal or forcing them to be equal), so you can use it for an assertion if the left hand side is a constant, as explained here.

So X = 3 would unify the variable X and the value 3, whereas 3 = X would attempt to unify the constant 3 with the current value of X, and be equivalent of assert(x==3) in imperative languages.

Answer 12

It depends on the programming language.

In Ruby, Smalltalk, Self, Newspeak, Ioke and many other single-dispatch object-oriented programming languages, a == b is actually a message send. In Ruby, for example, it is equivalent to a.==(b). What this means, is that when you write a == b, then the method == in the class of a is executed, but when you write b == a, then the method in the class of b is executed. So, it's obviously not the same thing:

class A; def ==(other) false end; end
class B; def ==(other) true  end; end

a, b = A.new, B.new

p a == b # => false
p b == a # => true