goto

Quote:

---

Originally posted by _uj
Fine but what does it mean? Separated from what logic. A goto is used to interrupt the normal flow of other control structures, but so is a break statement. There's no difference in principle. It's just that break has got a fancy name and become accepted over time. It's still a goto, as structured programming affectionados can tell you.

---

'if', 'while', 'switch/case' and 'for' have built-in well-defined branching logic. These largely replace any need for 'goto'. But alone they are not enough. There are some cases where you need more control for the looping constructs. 'break' and 'continue' help this. They both have a single well-defined purpose. 'goto' has no single well-defined purpose. 'break' is to break out of the loop. 'continue' will start with the next iteration on the loop. 'goto' could be used for either of these, or to jump to some exit/error condition, or to jump into the middle of some other if statement, or anything. Hence, there is no single well-defined purpose for it. That's the difference. It is separated from the reason for the branch.

Quote:

---

To use a goto once in a while as an extended break (jump to the exit point of a block) isn't the end of the world. It can even improve code because it can reduce the structural complexity of for example nested loops.

---

No, not the end of the world. An no, not every place it is used is a maintenance problem. And yes, it can be used conscientiously. I'll even admit there may be cases where it can reduce structural complexity. However, I have not seen such an example in ten years that couldn't be fixed by a better method than using goto. Before that, if I used it, it's only because I didn't know better.

'structural complexity' is a big concern of mine. I've always found a way to deconstruct complexity without resorting to goto. Take nested ifs as an example. There's usually a question you are trying to answer with the nested ifs. Maybe you are trying to get at an object through several layers and want to perform null checks on each layer. Maybe you are checking various statuses. Whatever the case, this logic can often be moved to a separate method.

'structural complexity' usually comes about because the method is trying to do too much. So, decompose the problem. Don't use goto. Future generations of maintainers will thank you.

Jeff

A break is connected to the logic of the while or for loop.

Quote:

---

Originally posted by KevinHall
A break is connected to the logic of the while or for loop.

---

Yes in C++ it is but Java for example is more liberal. There you can jump out of any block and even define labels to break to (within limits) like this,

Code:

---

  boolean b=false;
  repeat: {
        // ......
      if (b)
        break repeat;
  }

---

It's quite interesting that Java is more permissive than C++, it so seldom is. I think the reason is to furher reduce the need for a goto statement, the greater evil. ;)

Well, maybe the java people should post a thread in the Java forum about the evils of labelled break statements. ;)

Quote:

---

Originally posted by jfaust
It is separated from the reason for the branch.

---

The whole idea with the goto is that it's able to interrupt all other control structures at will. It's a very poverfull ability but this isn't why it should be avoided I think.

Structured programming is about complexity reduction and in some cases the goto, and it's cousin the break, actually does that. One example is when you jump out of nested loops and thereby simplify loop exit criteria.

The break is interesting because what you do is basically to trade logical complexity for structural complexity. With a break you make the loop exit criterium simpler, but you pay with a more complex loop structure. I personally find a few breaks easier to comprehend than a huge boolean exit expression with lots of and's and or's.

Well, I very much agree with what you say Jeff. I also think goto should be avoided, but I'm not that totally against. If you can accept the break you should also be able to accept the judicious use of a goto for a purpose. It's sloppy, lazy usage that should be banned.

Quote:

---

Originally posted by _uj
If you can accept the break you should also be able to accept the judicious use of a goto for a purpose. It's sloppy, lazy usage that should be banned.

---

I can agree with that, even though I doubt I will ever see a need to use it myself.

Another difficulty with it is that it's hard to put in a coding standards for a development team. It's much easier to say "don't use goto." Every team has a mix of talent and different areas of expertise. You may accept a poor programmer with a mostly fortran background if that person is an expert in the field, especially for scientific applications. Coding standards become very important, and increases with the size of the team. Effective rules can't be ambiguous.

Code reviews don't really help because it's very difficult to tell somebody to change something that works. But if you have a coding standard that prohibits it, you can ask them to change it without feeling like you're stepping on any toes.

Jeff

Quote:

---

Originally posted by jfaust
Another difficulty with it is that it's hard to put in a coding standards for a development team. It's much easier to say "don't use goto."

---

I see your point, but it's not just the goto's is it? C++ offers you an almost unlimited opportunity to screw up. At least that's my first impression. I have a Java background and in that language most of the dangerous stuff has been left out. Unfortunately some of the useful stuff too. That's why I'm here. :)

/Ulrika

Quote:

---

Originally posted by _uj
I see your point, but it's not just the goto's is it? C++ offers you an almost unlimited opportunity to screw up.

---

Certainly, but goto is much more likely to be misused. It can be employed in almost any scenario, but there are very few (if any) valid uses. And when misused, even when logically correct, creates a real maintenance headache. Moreso than any other C++ construct.

Except perhaps for compound ternary operators:

a = b ? c : d ? e : f;

:)

Jeff

Quote:

---

Originally posted by jfaust
Except perhaps for compound ternary operators:

a = b ? c : d ? e : f;

---

Well...that is actually one of my lifetime favourites...it has saved me so many 'if...else' keying... :cool:

Now don't make me mad, Andreas. You won't me when I'm mad. Veins start pulsing in my forehead and such.

Jeff

Quote:

---

Originally posted by jfaust
Certainly, but goto is much more likely to be misused. It can be employed in almost any scenario, but there are very few (if any) valid uses. And when misused, even when logically correct, creates a real maintenance headache. Moreso than any other C++ construct.

Except perhaps for compound ternary operators:

a = b ? c : d ? e : f;

---

I have a feeling the goto is just a minor problem in C++. On the level of structural programming it can wreak havoc of course but that's just on the C level. It's not a very big problem from a maintainance viewpoint really. The goto and the ternary operator must be very minor problems on the grand scale I'd say. The real problem with C++ must be at the OO side. How do you get a Fortran programmer to understand for example inheritance and how to use it correctly?