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

[monarch_dodra]

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.

[JohnW@Wessex]

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

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.
}

[ninja9578]

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.

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

folds to

if (true){ ... }

Whereas

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

folds to

if (true)
{ ... }

[potatoCode]

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.

// 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...

[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.

[monarch_dodra]

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.

[dshawul]

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.

[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;

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.

[ninja9578]

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

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

[potatoCode]

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

[ninja9578]

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.

[Feoggou]

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:

int x;

if (condition)
   x = 5;

than it would be by this:

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.

[nuzzle]

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.

[Zaccheus]

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

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

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

Oh but it does!

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.

[GCDEF]

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

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.