In C++ What Causes an Assignment to Evaluate as True or False When Used in a Control Structure

In C++ what causes an assignment to evaluate as true or false when used in a control structure?

In C++ an attribution evaluates to the value being attributed:

int c = 5; // evaluates to 5, as you can see if you print it out
float pi = CalculatePi(); // evaluates to the result
                          // of the call to the CalculatePi function

So, you statements:

if (a = b) { }
while (a = &c) { }

are roughly equivalent to:

a = b
if (b) { }
a = &c
while (&c) { }

which are the same as

a = b
if (a) { }
a = &c
while (a) { }

And what about those if (a) etc when they are not booleans? Well, if they are integers, 0 is false, the rest is true. This (one "zero" value -> false, the rest -> true) usually holds, but you should really refer to a C++ reference to be sure (however note that writting if (a == 0) is not much more difficult than if (!a), being much simpler to the reader).

Anyways, you should always avoid side-effects that obscure your code.

You should never need to do if (a = b): you can achieve exactly the same thing in other ways that are more clear and that won't look like a mistake (if I read a code like if (a = b) the first thing that comes to my mind is that the developper who wrote that made a mistake; the second, if I triple-check that it is correct, is that I hate him! :-)

Good luck

Trivial topic, does an assignment return 'false'?

The assignment operators like = and += return the value of the object after it's been assigned to. So, if you assign something false or 0, you can get false from the assignment operator.

i=5 evaluates to 5 and that's true in the eyes of if (). But i=0 would evaluate to 0 and that would be considered false by if ().

C++ | Boolean Values, which is true?

Any value that is not equal to zero is considered true. So the answer to the question is E since none of the listed values are zero.

Why doesn't using LET as an optional throw an error, as it is an implicit comparison to zero - inconsistency in Swift Intro book?

You are kind of right, it is not consistent, it should not mention Boolean Expression but rather a Logic Value. Here is what the Language Reference says about if:

The value of any condition in an if statement must have a type that conforms to the LogicValue protocol. The condition can also be an optional binding declaration, as discussed in Optional Binding.

Please note that optional binding here is not treated as an expression. It is not an assignment in if like in C. It is just a special case of an if statement that succeeds when the bound value is not nil.

None of this is valid in Swift:

x = y = 10 // () is not convertible to Int
if z = optional { } // type () does not conform to LogicValue
if let z = optional && z > 5 { } // bound value must be of Optional type
if (let z = optional) && z > 5 { } // pattern variable binding cannot appear in expression

Edit:
At first my answer stated that "assignment is not an expression in Swift", but technically that is incorrect. Assignment is an expression, but of type () a.k.a. Void. This is valid Swift:

var v = ()
var x = 0

v = x = 10 // x = 10; v = ()

Edit2:
Just to make this perfectly clear, when you use if let or if var it is not an assignment to an existing variable, a new variable/constant is introduced that is scoped to the inside of the if block:

var x = 0
var y : Int? = 10
if var x = y { // new variable x is introduced
    println(x) // prints 10
    x = 20     // neither affects y nor 'outer' x
}
if let x = y { // new constant x is introduced
    println(x) // prints 10
}
if let y = y { // introduce new y shadowing the original
    println(y) // prints 10
}
println(x)     // prints 0

//if x = y { } // does not compile

Control structures beyond standard conditionals and loops?

• Since Haskell is lazy, every function call is essentially a control structure.
• Pattern-matching in ML-derived languages merges branching, variable binding, and destructuring objects into a single control structure.
• Common Lisp's conditions are like exceptions that can be restarted.
• Scheme and other languages support continuations which let you pause and resume or restart a program at any point.

Why use short-circuit code?

For programmers, the benefit of a less verbose syntax over another more verbose syntax can be:

• less to type, therefore higher coding efficiency
• less to read, therefore better maintainability.

Now I'm only talking about when the less verbose syntax is not tricky or clever in any way, just the same recognized way of doing, but in fewer characters.

It's often when you see specific constructs in one language that you wish the language you use could have, but didn't even necessarily realize it before. Some examples off the top of my head:

• anonymous inner classes in Java instead of passing a pointer to a function (way more lines of code).
• in Ruby, the ||= operator, to evaluate an expression and assign to it if it evaluates to false or is null. Sure, you can achieve the same thing by 3 lines of code, but why?
• and many more...

---

Related Topics