[RESOLVED] Is there any difference between using {} and not using them?

[Feoggou]

I am curios of this:
Does the computer perform more operations if it happens to execute the following code:

if (condition) {return true;}

than it would execute the following code:

if (condition) return true;

Or it is the same thing for C++?

[Lindley]

The {} is only necessary if you wish to put more than one statement inside the if.

[GCDEF]

If there's only one statement following the if, they're the same. The braces create a code block which can include multiple statements.

These are the same

if(condition)
    DoSomething();

if(condition)
{
    DoSomething();
}

These are not

if(condition)
    DoSomething();
    DoSomethingElse();

if(condition)
{
    DoSomething();
    DoSomethingElse();
}

[monarch_dodra]

Note that even if they are necessary, it is usually a coding standard (and recommended) to always put them in anyways. The reason for this is that whenever later on you want your if to do 2 statements rather than one, there are good chances you'll forget to put them in.

My single statements if always look like this:

if ( condition )
    {statement;}

As you can see, the {} are not overly intrusive, and the indentation allows a clear flow of control. Placing the statement on a different line is important because allows a clear view of the debugger path. If I (or somebody else) wanted to add a second statement, all they'd to do is insert their statement under the first, and not worry about scope.

Don't fool yourself into thinking "I'm so good I don't need them". Even if it is true, it might not be true for everyone on your team, and there is no reason to turn down the help.

[ninja9578]

They are also great because IDE match them and let you fold things. Lots of times people put braces simply for that purpose.

Good example:

glPushMatrix(); {
     glBegin(GL_POLY); {
          //Graphics code
     } glEnd();
} glPopMatrix();

If the above code, the brace do nothing. It's not a block command like if, there are no variables for there to be a scope reason. The compiled code would be exactly the same as if they weren't there. They are purely there to know what glEnd goes to which glBegin in the IDE.

[nuzzle]

My single statements if always look like this:

if ( condition )
    {statement;}

But note that many (maybe most) official coding standards require this,

if (condition)
{
   statement;
}

[Xupicor]

And yet there are people that prefer:

if (condition) {
    //codey codey
}

or

if (condition)
    {
    //codey codey
    }

It really depends on the environment you are working in.

[Lindley]

I don't like either of those. I prefer

if (condition)
{
    // code
}

Much easier to visually pick out the blocks that way.

[GCDEF]

I don't like either of those. I prefer

if (condition)
{
    // code
}

Much easier to visually pick out the blocks that way.

I agree. I find the example ninja9578 posted particularly hard to read.

glPushMatrix(); {
     glBegin(GL_POLY); {
          //Graphics code
     } glEnd();
} glPopMatrix();

vs

glPushMatrix(); 
{
    glBegin(GL_POLY); 
    {
          //Graphics code
    }
    glEnd();
}
glPopMatrix();

Even then, I think they confuse more than they help.

[monarch_dodra]

I also prefer

if ( condition )
{
    //code
    //code
    //code
}

However, whenever you have several ifs with a single statement, the code starts to get too voluminous, and I find it becomes clearer with a single line block+instruction.

[dshawul]

I recently found myself using too many {} blocks to reclaim memory of big local variables with destructors.

{
      ScalarField   A ;
      do something with A;
      //destructor for A
}  
{
      ScalarField B;
      //destructor for B
}

is different from

ScalarField A;
ScalarField B;
dosomethig with A;
dosomething with B;

[Xupicor]

I don't like either of those. I prefer

if (condition)
{ 
    // code
}

Much easier to visually pick out the blocks that way.

Well, I like and prefer use the of first one, ie:

if (condition) {
    // code
}

//and 

if (condition) {
    // code
} else if (condition) {
    // code
} else if (condition) {
    // code
} else {
    // code
}

Since I feel like the line having only an opening bracket is pretty much wasted. It doesn't help me see the start of the loop/block at all, since that's what the indentation is for. It doesn't help me see functions from classes, since the "class" keyword is visible enough... So I don't use it unless I have to conform to a forced/team standard.

Bracket placement is one of those funny things... You can't really say this style is bad, and other is good (unless you compare utter chaos to a style ) - consistency is what matters more, I'd say.

[Joeman]

Much easier to visually pick out the blocks that way.

I agree with that . I used attached brackets when I was newer at programming, but I moved to broken brackets.

if( statement )
{
}

if( statement )
{
    // code
}
else if( statement )
{
    // code
}
else if( statement )
{
    // code
}

i like a switch statement before an else if when it is possible to use

switch( expression )
{
    case expression:
    {
        // code
    }
    break;

    case expression:
    {
        // code
    }
    break;

    default:
    break;
};

[monarch_dodra]

I recently found myself using too many {} blocks to reclaim memory of big local variables with destructors.

{
      ScalarField   A ;
      do something with A;
      //destructor for A
}  
{
      ScalarField B;
      //destructor for B
}

is different from

ScalarField A;
ScalarField B;
dosomethig with A;
dosomething with B;

So... what is the difference, and how is one better than the other one? IMO, the only noticeable difference is less name pollution in the first case.

switch( expression )
{
    case expression:
    {
        // code
    }
    break;

    case expression:
    {
        // code
    }
    break;

    default:
    break;
};

My switches always had the break statement inside the block, or even on the same line for single statement switches, but I like your style. I think I'll adopt it.

[laserlight]

So... what is the difference, and how is one better than the other one? IMO, the only noticeable difference is less name pollution in the first case.

There is a difference in scope and thus lifetime due to the use of RAII. I think dshawul already explained the idea: to release a resource - that may have a non-negligible cost to keep around - when it is no longer in use. In a way, it is akin to the idea of a scoped lock.