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

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.