Thread: I used my first goto statement today!

I think you're mixing up my "null reference" and "unchecked return value throws exception" experiments.

O_o

No.

This:

Code:

try{throw Something();}
catch(const Something & e){if(e){/* real exception */}else{/* control flow exception */}}

was a thing you posted.

Which is just one of the several times when a few regulars explained how exceptions aren't flow control constructs.

Exceptions may great control flow constructs.

You are only misusing the exception mechanism to control flow to pacify claims against `goto'.

You are just hiding one bad decision, pun a bad hack instead of fixing the code, with another in the hopes no one notices.

*shrug*

Well, you fooled anduril462 who doesn't know C++ all that well.

Soma

Originally Posted by Sebastiani

So instead of using goto in a proper, structured manner, you've resorted to breaking up a loop in a completely unnatural way (nevermind the issue of having clean access to variables from the calling function)?

I disagree. I find anduril462's example to be natural, idiomatic C++. Your version with goto to break out of nested loops (or in MutantJohn's case, a switch within a loop) is okay since the label comes at the end so it becomes a known idiom from C, but I would normally prefer anduril462's version because of the abstraction involved. MutantJohn's version with goto, on the other hand, I don't like because the label comes before the inner loop. Yes, it is somewhat of a continue, but it also more unusual and hence harder to understand.

Originally Posted by Sebastiani

In any case, I don't see how throwing an exception is such a "poor" choice. Exceptions make great control flow constructs.

Stroustrup disagrees: What shouldn't I use exceptions for?

phantom, the reason why a goto was used was because it was a simple solution to integrate and yes, it's pedantic. I can't imagine using a non-ISO compliant compiler. People know g++ is free, right? Also, if a goto was the bane of all existence then why did the developers spend time creating it?

O_o

Yeah, I know why you used `goto'. Fixing a hole with spackling paste is massively simpler than rebuilding the house.

I have no problem throwing away thousands of lines of code, but then, I'm obviously insane.

However, I can easily how you wouldn't want to start another rewrite after having just finished a rewrite.

Also, the "ISO-compliant compiler" thing is a "red herring". You could use `goto' with `if' instead of `while', but that doesn't make it the best choice. If the story of a better approach offends you, you should seek a different profession. The people in this thread aren't calling you out as a bad programmer for using the method as you have; we are only telling you of a more sophisticated method. Yes, we know, "GCC" is free. Yes, we also know, more or less, why `goto' is available to C++. We also know that this isn't a good fit for `goto' because the alternative method produces code that is much cleaner.

[Edit]
Here "cleaner" is meaning "more canonical", "more idiomatic", and "more natural to C++" making it, as laserlight implies, easier to understand for other C++ programmers.

You are using this code, indirectly, for you resume, yes? Well, a great C++ programmer reviewing your example code for the sake of interview wants to see code that he/she instantly recognizes as good C++ that other programmers working for the company can readily maintain.
[/Edit]

Soma

Originally Posted by MutantJohn

I'd also like to mention that if I was immediately fired for using a goto without being told to at least go back and rewrite my code then that'd be a very stressful job.

phantom, the reason why a goto was used was because it was a simple solution to integrate and yes, it's pedantic. I can't imagine using a non-ISO compliant compiler. People know g++ is free, right? Also, if a goto was the bane of all existence then why did the developers spend time creating it?

I think the first reply in this thread was right. It's not the best use of a goto but it's not bad. It doesn't break my code and for once, I can actually triangulate 8000 points whereas before I couldn't triangulate 4000 not using goto as a means of iteration. I like using goto in this context because it doesn't obfuscate my code from what it was before. Now, I will look into the use of stacks but in the meantime, a goto seems to suffice just fine. I will analyze the time it would take to rework the structure of my code and see if it's exactly that much better of an implementation to use stacks.

Also, my code really looks likes this :

Code:

for (auto it = fract.begin(); it < fract.end(); ) {

   test :

   tetra *t = *it;

   for (int i=0; i<4; i++) {

      if (t->ngb[i]) {

          auto distance = std::distance(fract.begin(), it);

          switch (x) {

               case 23 :

                     if (two_to_three(fract, inherit, t, t->ngb[i], plane, x, y) == 0)
                        it = fract.begin() + distance;
                     else
                     it++; 
                     if (it >= fract.end()) return;

                    goto test;
           }
      } if (i == 3) it++;
   }
}

This way, it's a bit more clear to see what I'm doing. I don't know... A goto was a simple solution to a problem that presented itself and so far, my code seems stable. You can use non-compliant compilers all you want and I'm not guaranteeing that my code will work. But as far as I can tell, the -pedantic flag is silent during compilation so it's ISO cleared and if you're compiler isn't ISO compliant then whose fault is that? I can't write for every possible scenario or odd compiler you use. Hopefully the VB compiler is ISO compliant...

Well, let me just say that while using goto to break out of a loop is acceptable (IMO), the way in which you are using it is arguably just the sort of practice that has led to it's marginalization as a language feature! The reason being is that you can easily fall into the pitfall of structuring more and more of your code around such constructs (ie: spaghetti code) and pretty soon only you and God (or maybe just God) can follow it. More specifically, jumping to code ABOVE is generally considered bad practice, whereas DOWNWARD is okay ONLY IF THERE IS NO OTHER ROUTE. In most cases, gotos are reall not necessary in the first place...

And you don't have to cover every "odd" compiler, but you certainly can avoid writing code that most compilers will screw up. Compilers are imperfect, that's life in the real world.

^_^

@MutantJohn:

Okay. Well, anduril462 said that beautifully so I couldn't possibly add anything meaningful to it, but I'm going to add some context all the same.

I offer this context for a simple reason: don't start thinking you'll get to pick your tools forever.

Now, you may be surprised, but a lot of the regulars here don't even do C++ for a living. Those that do or have done can tell you, a lot of C++ houses will have you throwing code at multiple compilers. (You should ask grumpy for I think he has such work.) You aren't going to get by with just "G++". The point is, you may very well be expected to compile code that works despite the quirks of several different compilers.

I wish I could have said it, I wish I could say it better, but I can't so I'll just quote it again "And you don't have to cover every "odd" compiler, but you certainly can avoid writing code that most compilers will screw up. Compilers are imperfect, that's life in the real world.".

Let me tell you MutantJohn, that's a bit of truth you can take to the bank.

Soma

Originally Posted by laserlight

I disagree. I find anduril462's example to be natural, idiomatic C++. Your version with goto to break out of nested loops (or in MutantJohn's case, a switch within a loop) is okay since the label comes at the end so it becomes a known idiom from C, but I would normally prefer anduril462's version because of the abstraction involved. MutantJohn's version with goto, on the other hand, I don't like because the label comes before the inner loop. Yes, it is somewhat of a continue, but it also more unusual and hence harder to understand.

Well, I do agree with you on his placement of the goto label (not present in his original post, see my response later), but insofar as breaking out of a loop I see it as a non-issue; the goto is the most logical choice. That said, the fact that it is more often than not used incorrectly (as demonstrated by the OP's proposed solution), I humbly cede the floor to you on this one.

Originally Posted by laserlight

Stroustrup disagrees: What shouldn't I use exceptions for?

With all due respect, AFAIK that's based solely on someone's personal opinions/tastes concerning the "proper" use of exceptions, and as such I could care less.

Originally Posted by Sebastiani

not present in his original post

It is present as stated within the text in post #1: "I just put a label or w/e before my int for-loop". I have no clue what does "w/e" mean though. Hmm...

Originally Posted by Sebastiani

With all due respect, AFAIK that's based solely on someone's personal opinions/tastes concerning the "proper" use of exceptions, and as such I could care less.

That someone happens to be the designer and original implementer of C++, and one of the key people on the standard committee when exceptions were standardised in C++. It seems like you did not read the two reasons that were provided:

• not idiomatic in C++: confuse most C++ programmers used to seing exceptions used only for error handling.
• slow: deliberately not supported well by C++ implementations (those implementations are optimized based on the assumption that exceptions are used for error handling)

Originally Posted by laserlight

It is present as stated within the text in post #1: "I just put a label or w/e before my int for-loop". I have no clue what does "w/e" mean though. Hmm...

Okay, well it wasn't stated clearly at least.

Originally Posted by laserlight

That someone happens to be the designer and original implementer of C++, and one of the key people on the standard committee when exceptions were standardised in C++. It seems like you did not read the two reasons that were provided:

• not idiomatic in C++: confuse most C++ programmers used to seing exceptions used only for error handling.
• slow: deliberately not supported well by C++ implementations (those implementations are optimized based on the assumption that exceptions are used for error handling)

It's a language, not a religion. I reserve the right to use it as I see fit.

Originally Posted by Sebastiani

It's a language, not a religion. I reserve the right to use it as I see fit.

Certainly, but I note that you have not addressed the reasons given, and merely stuck to your proclamation that "exceptions make great control flow constructs" as if it were infallible dogma

Sorry, telling me that I'll be instantly fired does NOT help me.

O_o

I fear you misunderstood the context of the "fired" comment, and for that, I apologize.

I reread it now, and I can see how you thought I was attack you.

I was attacking the code example I quoted which wasn't even suggested by you.

The code I attacked is intentionally and knowingly misusing a feature of the language to the detriment of maintainability.

(Yes, Sebastiani absolutely knew where exception as flow control was headed. We've had this exact argument before. Yes, the same players. I'd be surprised if he hadn't expected the Stroustrup link from laserlight.)

There is a huge difference between writing code that just needs some fixes and purposefully writing code that other programmers will find difficult to maintain for whatever reason.

You know, let me elaborate to eliminate any remaining confusion:

You say that you are going to explore the suggestions as offered. In other words, you are, I expect, going to try and refactor the code and learn from the experience so that you might, in the future, write canonical and idiomatic C++ that other C++ programmers will find to be good and maintainable C++.

Sebastiani knows that the vast majority of C++ programmers will be put off by the code and so find it more difficult to maintain, yet has no intention of writing canonical and idiomatic C++.

You see what I mean? The code Sebastiani offered is a very different beast.

To be fair, I've lost more jobs than I've had precisely because I do not work well with others.

I get what you're trying to do though, phantom. I feel like you're trying to push me. You're trying to actually help me become a professional programmer. Thank you. That means a lot to me.

You seem like a good guy, and I hope you get a good job, but then I really don't really care if you get a job.

More importantly, to me, you seem like you are willing to bash your head against the wall until you figure stuff out.

I'm trying to push you along the path of a great C++ programmer.

^_^

Of course, being a great C++ programmer will make you more employable so it all works out.

[Edit]
Actually, you know, it doesn't matter. Sebastiani is so much like Elysia in this regard it actually gives me a chuckle.
[/Edit]

[Edit]
@laserlight: I admit; it is as much my fault as any, but now may be a good time to split this thread before the other two regulars show up and we get a repeat of the 100 post monster.
[/Edit]

Soma

Originally Posted by laserlight

Certainly, but I note that you have not addressed the reasons given, and merely stuck to your proclamation that "exceptions make great control flow constructs" as if it were infallible dogma

1) Exceptions are by definition and perforce flow-control constructs. The idea that they should only be used to signal errors is a convention. But really they are just a mechanism to ascend from the call stack in such a way that guarantees execution of certain blocks of code, and as such they have many uses above and beyond mere error propagation.
2) How much affect they have on performance is a matter of debate and circumstance. Sometimes they lead to a speed up in code execution, in fact. Again, it just depends.

Originally Posted by Sebastiani

1) Exceptions are by definition and perforce flow-control constructs. The idea that they should only be used to signal errors is a convention. But really they are just a mechanism to ascend from the call stack in such a way that guarantees execution of certain blocks of code, and as such they have many uses above and beyond mere error propagation.

I would argue that it is not just convention: it is by design. Furthermore, convention plays an important role in good design and readability. Granted, sometimes we might ignore the original design intentions and convention, allowing for arcane code in exchange for some benefit (template metaprogramming and Boost.Spirit comes to mind), but here constructs already exist to handle the logic efficiently in a conventional way. There is simply no benefit in abusing exceptions to perform normal flow control. Concerns about compiler bugs aside, your goto example would be a far better solution because that is a well known use for goto (even though it has its detractors allergic to all use of goto).

Originally Posted by Sebastiani

2) How much affect they have on performance is a matter of debate and circumstance. Sometimes they lead to a speed up in code execution, in fact. Again, it just depends.

I believe that the common cases where they lead up to a speed up in code execution is because the exception mechanism was not actually invoked. That fits the bill for error handling in that if there is no error, there is minimal cost, as opposed as to always having to explicitly check for the error at the call site. In normal flow control, on the other hand, the condition involved might always become true at some point, as in the case of getting out of a loop.