goto

What exactly about the goto is bad but the if good? What I am getting at is that this is just a code fashion preference. Some might say to use a switch, some if, some goto. The reason I picked this as an example is that it precisely relates to these issues and does not give goto an unfair advantage (such as stepping out of nested blocks, which allows one to exit without the need to pollute variable namespace and does not make the original logic more complex with variable tests to exit). I understood completely that the fragment I posted was possible in many other ways. What I desire, though, is a reason why it is worse than the alternatives. Each alternative has its own blocking structure that may or may not be useful. I personally would use an if on the occasion that I needed to declare more variables, because it provides the proper block structure I desire. Remember, I didn't put any variable declarations in my original code. But I still would not have a problem if one of my developers submitted something like that.

So, why is goto bad but the if good?

goto is an unconditional branch that is separated from the reason for the branch. Other control structures have the reason built in.

Jeff

One thing is also that goto has no programming logic built into it. When you see a for loop you know what it is. When you see an if () statement you know what it is and how it behaves. When you see a goto, it could mean pretty much anything.

The goto statement doesn't hold any information about what the semantics of the code are. This is a loss when you could use a statement that has in-built semantics.

This does not mean I'm entirely against goto in all cases, but most of the time it's clearer to use a more appropriate statement. Of course this hasn't been said before :D

jfaust, I concede to your superior debate move. Absolutely! It makes absolute sense. Because it should be a design principle that one should keep a branch connected to the logic of the branch. And so, this design principle invalidates the use of goto ever. Of course, I could argue that one could still use goto if the branch condition is connected to the goto in a complete statement group (if, goto) but then you have maintainability issues. Brilliant!

** galathaea spins melodramatically at the fatal shot to the heart **

Whispered, last gasp: "I have been fell by the greater rhetorics of jfaust. All should follow his advice. Never use goto."

galathaea,

You must be the most fun person to debate with. ;)

Thanks for pressing the issues--made me think more about it than I have before. It's always good to revisit 'beliefs', and see if there's any sense to them.

Jeff

Quote:

---

One thing is also that goto has no programming logic built into it. When you see a for loop you know what it is. When you see an if () statement you know what it is and how it behaves. When you see a goto, it could mean pretty much anything.

---

Some times less information is better information. I do not think goto mean "pretty much anything". It has only one unambiguious meaning: Jump to where label specifies.

Your boss may tell you: step outside the office door, make a left, go downstairs, make a right, exit the building, left turn into a place where a lot of cars are parked, get in your car, exit the parking lot and get on the highway, etc. etc. All these are very specific and very detailed information but the more specific it is, the more confused you will be. You boss might just tell you to "go home and come back tomorrow". It's a much less specific instruction but it is much less confusing.

goto is pretty useful and helps readability where there are multiple opening and closing curly brackets ({}'s) between the goto statement and where the goto label is. It is more so when the code is badly formatted and it is hard to match opening and closing {'s and }'s.

See this code:

Code:

---


    //...
    break;
    }}}}}}
    //..
    {
    //..
    // A couple hundred code lines.
    }}

here_we_go:

---

So by reading the above code, how is it clear to you that when it hit the break statement, it will break all the way out of all the {'s and }'s and lead you next to here_we_go?

To reach that conclusion, you would have to look at each { and }, find its matching partner, and look at whether it is a for loop, a if/else or a while, and decide whether you should break out of that scope. If there are a dozen of them, and the opening and closing {}'s are several hundred lines apart from each other, plus they are not formatted to be aligned with each other, you will have a VERY DIFFICULT TIME figuring out where you go, after the break statement.

Where as if I used goto, it's going to be a no-brainer where I go next.

Well, if I would take that point further, I would never use break in any program since that statement also doesn't hold any semantics. You pointed this out quite successfully in your example.

But, the point I was trying to make about goto is that if there is an option with semantics, prefer that one.

As to my statement that goto can mean anything... It depends on how the programmer uses it, but as you know assembly, you know what you can do with unconditional jumps. So well, let's say pretty much anything ;)

Code:

---

  if (i == 5) goto label_true
  result = 16;
  goto label_end
label_true:
  result = 25
label_end:

---

if-then-else loop for example

Code:

---

  i = 0;
label_loop:
  if (i >= 5) goto label_end
  result = result * i
  goto label_loop
label_end:

---

for loop...

Code:

---

  for (i = 0; i < 5; i++) {
    if (i == 3) goto label_break
  }
label_break:

---

the break example...

etc...

P.S. I actually never use break in any program ;) There is nothing evangelical about it but I just don't find the need for it.

Hi, all. Here one reason to use "goto":

Say you have long sequence of system calls.
Each system call you have to check return value.
If system call failed, the rest of sequence is useless,
but you have to clean-up some handlers.

With ussage of goto, the code is like this:

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free_param(param);

Now, with C++ you have alternative - throw exception.
Or you can split it to set of subfunctions and do cleanup
in other function at all.
Both alternative solutions that I see are longer and harder.

Do you have better solution ?

Hi, all. Here one reason to use "goto":

Say you have long sequence of system calls.
Each system call you have to check return value.
If system call failed, the rest of sequence is useless,
but you have to clean-up some handlers.

With ussage of goto, the code is like this:

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free_param(param);

Now, with C++ you have alternative - throw exception.
Or you can split it to set of subfunctions and do cleanup
in other function at all.
Both alternative solutions that I see are longer and harder.

Do you have better solution ?

Quote:

---

Originally posted by arkadi
Do you have better solution ?

---

Yes. You are trying to do too much in one method. Break it up. Have one simple well-defined purpose per method. If you have system calls that allocate memory, wrap that logic in a simple class that handles the deallocation in the destructor. There are several things you can do to clean this up, even if you ignore the use of goto.

Besides, I don't think your contrived example is valid. You are allocating memory several times and only freeing it once.

Jeff

Quote:

---

Besides, I don't think your contrived example is valid. You are allocating memory several times and only freeing it once.

---

You know, it`s pseudo code :)

param = malloc(size_param);

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free(param);

Quote:

---

Break it up. Have one simple well-defined purpose per method. If you have system calls that allocate memory, wrap that logic in a simple class that handles the deallocation in the destructor

---

Yes, it is solution. But:
Does it make code cleaner ?
Does it make writing code faster ?
When you come to somebody`s old code, what do you prefer:
10 strokes that uses "goto"
or 50 that implements work-around ?

Quote:

---

Originally posted by arkadi
Does it make code cleaner ?

---

Yes.

Quote:

---

Does it make writing code faster ?

---

Almost always not an issue. And if it is, inlining can solve it.

Quote:

---

When you come to somebody`s old code, what do you prefer:
10 strokes that uses "goto"
or 50 that implements work-around ?

---

I'm not talking about implementing a work-around. "Not using goto" is not a work-around. It's a good coding practice for all the reasons brought up previously. Wrapping resource in objects that free the memory on destruction is also a good practice--look up RAII for more information.

When all of this is done, your example could be less than 10 lines, and certainly not 50.

Jeff

I've worked on systems where error handling needed to be done like that. Actually, rather than using gotos, the following code was used:

Code:

---

int aFunction()
{
    int res;

/* Some enter function trace statements */

    res = fn1();

    if (res == 0)
    {
        res = fn2();
    }

    if (res == 0)
    {
        res = fn3();
    }

    if (res == 0)
    {
        res = fn4();
    }

    /* ... */

    /* Some cleanup */

    /* Some exit function trace statements */

    return res;
}

---

The need here was to maintain a single exit point for the functions so that traceing would work -- and the functions WERE split up appropriately with good structure. Personally, I think that goto's would have performed better when an error did occur. However, the argument against this was "we only care about performance when things are working as they should." This seemed to be valid for the application in question.

- Kevin

Quote:

---

When all of this is done, your example could be less than 10 lines, and certainly not 50.

---

While other reasons are matter of taste, this can be shown.
Please, submit your solution.

Quote:

---

Originally posted by arkadi
While other reasons are matter of taste, this can be shown.
Please, submit your solution.

---

More than a matter of taste. We've tried to show the dangers of using goto. But anyway, here's my solution. The code provided above was not a real-world example, so neither will this be a real-world solution. Most importantly, the names will not be meaningful.

Code:

---

// should use a more meaninful name
class ResourceAquirer
{
public:
    ResourceAquirer()
      : m_param(0)
    {
    }

    ~ResourceAquirer()
    {
          if( m_param )
              free(m_param);
    }

    // this would be a more meaningful method, perhaps returning
    // the string from the registry.
    res_type getResource() const
    {
          // The logic goes here to allocate the resource if it has not
          // been already, aka lazy evaluation/initialization.
          if( m_param )
          {
              return m_param;
          }

          m_param = malloc(param_size);

          // Now get the resource.  Note there's no need for a
          // cleanup section since the memory is freed in the
          // destructor, hence no desire to use goto.
    }

private:
    res_type  m_param
};

int aFunction()
{
    ResourceAquirer r;
    if( res_type res = r.getResource() )
    {
          // use resource or better yet, put the logic into
          // the ResourceAquirer class to use the resource.
    }
}

---

Now we have a reusable class that maintains the logic and the memory of aquiring a certain resource. This can be safely reused where needed. Note the user does not have to ever worry about freeing up any resource. It will be freed for him, even in the face of a thrown exception.

Jeff