lajos
lajos

Reputation: 25715

Why would you use an assignment in a condition?

In many languages, assignments are legal in conditions. I never understood the reason behind this. Why would you write:

if (var1 = var2) {
  ...
}

instead of:

var1 = var2;
if (var1) {
  ...
}

?

Upvotes: 96

Views: 118838

Answers (12)

Priteem
Priteem

Reputation: 11

I used it today while programing in Arduino (Subset of C++ language).

Case

I have a transmitter and a receiver. The transmitter wants to send the data until it is received. I want to set a flag when the process is done.

while (!(newtork_joined = transmitter.send(data))) {
Serial.println("Not Joined");
}

Here:

  • "transmitter.send" - returns true when the transmission is successful
  • "newtork_joined " - is the flag I set when successful

Result

  1. When the transmission is not successful, the flag is not set, while loop is true, it keeps executing

  2. When successful, the flag is set, while loop is false, we exit

Isn't beautiful?

Upvotes: 0

plasmixs
plasmixs

Reputation: 156

The other advantage comes during the usage of GDB.

In the following code, the error code is not known if we were to single step.

while (checkstatus() != -1) {
    // Process
}

Rather

while (true) {
    int error = checkstatus();
    if (error != -1)
        // Process
    else
        // Fail
}

Now during single stepping, we can know what was the return error code from the checkstatus().

Upvotes: 2

Hugh Allen
Hugh Allen

Reputation: 6695

The short answer is that expression-oriented programming languages allow more succinct code. They don't force you to separate commands from queries.

Upvotes: 4

Gerald
Gerald

Reputation: 23499

It's more useful for loops than if statements.

while(var = GetNext())
{
  ...do something with 'var' 
}

Which would otherwise have to be written

var = GetNext();
while(var)
{
  ...do something
  var = GetNext();
}

Upvotes: 133

Gangadhar
Gangadhar

Reputation: 1

The reason is:

  1. Performance improvement (sometimes)

  2. Less code (always)

Take an example: There is a method someMethod() and in an if condition you want to check whether the return value of the method is null. If not, you are going to use the return value again.

If(null != someMethod()){
    String s = someMethod();
    ......
    //Use s
}

It will hamper the performance since you are calling the same method twice. Instead use:

String s;
If(null != (s = someMethod())) {
    ......
    //Use s
}

Upvotes: -4

Julien-L
Julien-L

Reputation: 5416

I find it very useful with functions returning optionals (boost::optional or std::optional in C++17):

std::optional<int> maybe_int(); // function maybe returns an int

if (auto i = maybe_int()) {
    use_int(*i);
}

This reduces the scope of my variable, makes code more compact and does not hinder readability (I find).

Same with pointers:

int* ptr_int();

if (int* i = ptr_int()) {
    use_int(*i);
}

Upvotes: 0

Jonathan Leffler
Jonathan Leffler

Reputation: 754480

I find it most useful in chains of actions which often involve error detection, etc.

if ((rc = first_check(arg1, arg2)) != 0)
{
    report error based on rc
}
else if ((rc = second_check(arg2, arg3)) != 0)
{
    report error based on new rc
}
else if ((rc = third_check(arg3, arg4)) != 0)
{
    report error based on new rc
}
else
{
    do what you really wanted to do
}

The alternative (not using the assignment in the condition) is:

rc = first_check(arg1, arg2);
if (rc != 0)
{
    report error based on rc
}
else
{
    rc = second_check(arg2, arg3);
    if (rc != 0)
    {
        report error based on new rc
    }
    else
    {
        rc = third_check(arg3, arg4);
        if (rc != 0)
        {
            report error based on new rc
        }
        else
        {
            do what you really wanted to do
        }
    }
}

With protracted error checking, the alternative can run off the RHS of the page whereas the assignment-in-conditional version does not do that.

The error checks could also be 'actions' — first_action(), second_action(), third_action() — of course, rather than just checks. That is, they could be checked steps in the process that the function is managing. (Most often in the code I work with, the functions are along the lines of pre-condition checks, or memory allocations needed for the function to work, or along similar lines).

Upvotes: 42

JesperE
JesperE

Reputation: 64424

GCC can help you detect (with -Wall) if you unintentionally try to use an assignment as a truth value, in case it recommends you write

if ((n = foo())) {
   ...
}

I.e. use extra parenthesis to indicate that this is really what you want.

Upvotes: 15

Paige Ruten
Paige Ruten

Reputation: 176743

In PHP, for example, it's useful for looping through SQL database results:

while ($row = mysql_fetch_assoc($result)) {
    // Display row
}

This looks much better than:

$row = mysql_fetch_assoc($result);
while ($row) {
    // Display row
    $row = mysql_fetch_assoc($result);
}

Upvotes: 3

Greg Hewgill
Greg Hewgill

Reputation: 993901

The idiom is more useful when you're writing a while loop instead of an if statement. For an if statement, you can break it up as you describe. But without this construct, you would either have to repeat yourself:

c = getchar();
while (c != EOF) {
    // ...
    c = getchar();
}

or use a loop-and-a-half structure:

while (true) {
    c = getchar();
    if (c == EOF) break;
    // ...
}

I would usually prefer the loop-and-a-half form.

Upvotes: 10

Chris Young
Chris Young

Reputation: 15767

It's more useful if you are calling a function:

if (n = foo())
{
    /* foo returned a non-zero value, do something with the return value */
} else {
    /* foo returned zero, do something else */
}

Sure, you can just put the n = foo(); on a separate statement then if (n), but I think the above is a fairly readable idiom.

Upvotes: 31

Michael Burr
Michael Burr

Reputation: 340316

It can be useful if you're calling a function that returns either data to work on or a flag to indicate an error (or that you're done).

Something like:

while ((c = getchar()) != EOF) {
    // process the character
}

// end of file reached...

Personally it's an idiom I'm not hugely fond of, but sometimes the alternative is uglier.

Upvotes: 27

Related Questions