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

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

Code:

---

if (condition) {return true;}

---

than it would execute the following code:

Code:

---

if (condition) return true;

---

Or it is the same thing for C++?

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

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

Code:

---

if(condition)
    DoSomething();

if(condition)
{
    DoSomething();
}

---

These are not

Code:

---

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

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

---

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:

Code:

---

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.

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:

Code:

---

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.

Quote:

---

Originally Posted by monarch_dodra

My single statements if always look like this:

Code:

---

if ( condition )
    {statement;}

---

---

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

Code:

---

if (condition)
{
  statement;
}

---

And yet there are people that prefer:

Code:

---

if (condition) {
    //codey codey
}

---

or

Code:

---

if (condition)
    {
    //codey codey
    }

---

It really depends on the environment you are working in.

I don't like either of those. I prefer

Code:

---

if (condition)
{
    // code
}

---

Much easier to visually pick out the blocks that way.

Quote:

---

Originally Posted by Lindley

I don't like either of those. I prefer

Code:

---

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.

Code:

---

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

---

vs

Code:

---

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

---

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

I also prefer

Code:

---

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.

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

Code:

---

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

---

is different from

Code:

---

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

---

Quote:

---

Originally Posted by Lindley

I don't like either of those. I prefer

Code:

---

if (condition)
{
    // code
}

---

Much easier to visually pick out the blocks that way.

---

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

Code:

---

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.

Quote:

---

Originally Posted by Lindley

Much easier to visually pick out the blocks that way.

---

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

Code:

---

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

Code:

---

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

    case expression:
    {
        // code
    }
    break;

    default:
    break;
};

---

Quote:

---

Originally Posted by dshawul

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

Code:

---

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

---

is different from

Code:

---

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.

Quote:

---

Originally Posted by Joeman

Code:

---

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.

Quote:

---

Originally Posted by monarch_dodra

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.

Quote:

---

Originally Posted by laserlight

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.

---

Well, yeah. But he was making it sound like it was a bad thing to do.

Another thing to remember is that having the 'DoSomething' on a different line allows you to debug more easily.

Code:

---

if(condition) DoSomething(); // Without 'stepping in' we don't know if DoSomething() was called or not.

if(condition)
{
    DoSomething();  // We can put a breakpoint here.
}

---

I still prefer putting the bracket on the end of the line, it makes it easier for me to see what it matches up with, plus it folds better.

Code:

---

if (true){
  foo();
  bar();
}

---

folds to

Code:

---

if (true){ ... }

---

Whereas

Code:

---

if (true)
{
  foo();
  bar();
}

---

folds to

Code:

---

if (true)
{ ... }

---

I agree with monarch_dodra on going with what is accepted at the working environment.

There's one thing that I can't quite decide which way to go, i.e.

Code:

---

// case 1
template <typename Type>
const T foo(const Type& arg1, const Type& arg2 /* and smoe more */)

// case 2
template <typename Type>
const T foo(const Type& arg1,
            const Type& arg2
            /* and some more */)
// case 3
template <typename Type>
const T foo(
            const Type& arg1,
            const type& arg2
            /* and some more */
            )

---

The naming convention and the brackets, I can pretty much deal with because, well, it has been discussed to death, but the placement of the ending parenthesis has been not (well at least for me) Although I'm a big fan of having lots of small functions rather than a big one and design from the user's point of view, sometimes functions with many number of parameters are just ..there.

This gets even worse when working with the templates because I agree with the notion that a good naming convention (and no, I don't favor the hungarain notation) can avoid writing a seperate document for it.

I still can't make up my mind on this.

EDIT:
I forgot to mention the case where nesting functions...

I tend to use case 1 for functions with one or two parameters and case 2 for when there are more or when the parameter definitions are long, such as when using templates or deep namespaces.

Quote:

---

Originally Posted by JohnW@Wessex

I tend to use case 1 for functions with one or two parameters and case 2 for when there are more or when the parameter definitions are long, such as when using templates or deep namespaces.

---

Ditto.

As for the closing parenthesis, or the position of the first parameter (first/second line), or the alignement (everything under the first parameter, or just 1 indentation), I think it is such subtle differences that nobody really cares. Or at least doesn't care enough to make it a standard.

Quote:

---

Originally Posted by monarch_dodra

Well, yeah. But he was making it sound like it was a bad thing to do.

---

I don't know where you got that from ?? I said I was forced to use scoping because I can't have two big local variables (ScalarField is like 1 million doubles f.i). At first I had c-style variable declarations all at the beginning. I switched to declaration of variables with in different scopes and now I can solve 6x bigger problems.

Quote:

---

Originally Posted by dshawul

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

Code:

---

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

---

is different from

Code:

---

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

---

---

Quote:

---

Originally Posted by dshawul

I don't know where you got that from ?? I said I was forced to use scoping because I can't have two big local variables (ScalarField is like 1 million doubles f.i). At first I had c-style variable declarations all at the beginning. I switched to declaration of variables with in different scopes and now I can solve 6x bigger problems.

---

Your "too many" made it sound to me like it was a bad thing to do. Which is confusing, because as you say, it is actually a good thing to limit scope. So I wanted to know. Guess I miss-understood.

Quote:

---

Originally Posted by potatoCode

EDIT:
I forgot to mention the case where nesting functions...

---

C++ has no support for this, very few languages do.

Quote:

---

Originally Posted by ninja9578

C++ has no support for this, very few languages do.

---

Haha. I meant nesting function CALLS
But that 's' at the end of the word function was surely misleading

Ooh, I see what you meant now. I've been writing php, which is one of the few languages with nested functions, I guess it was on my brain.

ok guys, thanks for the answers.
I thought that maybe, internally, the computer executes a different number of operations/instructions, so that there would be less instructions/operations executed by this:

Code:

---

int x;

if (condition)
  x = 5;

---

than it would be by this:

Code:

---

int x;

if (condition)
{
  x = 5;
}

---

But, if you say that it's ok, that's nice. There is code that I sometimes change, from many instructions executed by an if (where you really need brackets) to a single instruction, and sometimes I leave the brackets there. I thought that it might be bad programming or something.

Sorry, I think this question needed a bit of knowledge of assembly or alike (how it is implemented), but it was a c++ issue, so I guess this was the proper place to ask this question.

Quote:

---

Originally Posted by Feoggou

Sorry, I think this question needed a bit of knowledge of assembly or alike (how it is implemented), but it was a c++ issue, so I guess this was the proper place to ask this question.

---

Yes it's a C++ issue but above all it's a program design issue.

Write the simplest most easy to understand code possible. Putting in a few extra not strictly necessary brackets or parentheses for the sake of clarity will never slow down your code. And never cram code into one-liners. It's not efficient, just error-prone. One line - one thought, is a good rule of thumb.

There's a division of labour here. You write clear easy to maintain C++ code and the compiler will produce efficient assembly for you.

I would always use braces, but I think it is ok to do the following:

Code:

---

switch (a)
{
    case 1: { f(); break; }
    case 2: { g(); break; }
    default: // Do nothing.
};
if(b) { f(); }

---

Quote:

---

Originally Posted by ninja9578

C++ has no support for this [local functions], very few languages do.

---

Oh but it does!

Code:

---

int f(int a)
{
    struct Local
    {
        inline static int g(int x)
        {
            return x * x;
        }
    };


    return Local::g(a) * Local::g(a);
}

---

I've used this in the past for very simple helper functions.

:D

Quote:

---

Originally Posted by Zaccheus

I would always use braces, but I think it is ok to do the following:

Code:

---

switch (a)
{
    case 1: { f(); break; }
    case 2: { g(); break; }
    default: // Do nothing.
};
if(b) { f(); }

---

---

I disagree. Multiple statements on one line are hard to read and hard to debug. It's a bad habit IMHO.

Quote:

---

Originally Posted by Zaccheus

Oh but it does!

Code:

---

int f(int a)
{
    struct Local
    {
        inline static int g(int x)
        {
            return x * x;
        }
    };


    return Local::g(a) * Local::g(a);
}

---

I've used this in the past for very simple helper functions.

:D

---

Yes, but that's not true nested functions ;)