I used my first goto statement today!

Why would I use the black art known as goto? Well, I had some code like this,

Code:

---

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

for (int i=0; i<4; i++) {
  if (t[i]) {

      switch (x) {

        case 23 :
            /* needed to go back to iterating through my vector here */
      }
  }
}
}

---

Turns out, I completely forgot that 'break' will break you out of a switch before a loop so I just put a label or w/e before my int for-loop and omg, my code actually works properly now or at least, I have successfully replaced recursion with iteration.

Sorry, I just felt like sharing. goto's are actually pretty sweet. I'm going to needlessly fill my code with them from now on.

Hmm...not the worst use of a goto, but probably not the best either. There have been times that I really wish C supported labeled break/continue statements, but that's becoming rare. I am more than happy to simply move stuff into helper functions:

Code:

---

for (auto it = vec.begin(); it < vec.end(); ) {
    process_vector_elements()
}
...
void process_vector_elements()
{
    for (int i = 0; i < 4; ++i) {  // use pre-increment in C++
        if (t[i]) {
            switch (x) {
                case 23:
                    return;

---

When it hits that return, and process_vector_elements is done, the vector loop will proceed to the next element.

As for the pre-increment, it avoids having to call a copy constructor (since it doesn't have to save the old value of i).

The other nice thing about splitting up your function like this is you've separated the processing of a vector of objects, from the processing of a single object. That keeps your code loosely coupled and makes it easier to do things like unit test your code, since you have isolated the processing of a single foo object. And it will keep your code (or at least this part of it) goto-free.

Also, I hope you're not using magic numbers (4 and 23) in the real code. Some #defines and enums would do nicely here.

Last note:
This definitely seems to be C++. I'm not much of a C++ expert, but I can't recall ever seeing a good use of goto in C++. In C, however, the most common use that I've seen (and personally the only one I generally think is a good use of goto) is for error handling, so you can avoid deeply-nested if statements or repeating tedious cleanup code.

How does your method affect the call stack though? The only reason I ask is because I have recursive code that overflows the stack with calls. So today I made it iterative and not recursive.

Quote:

---

Originally Posted by MutantJohn

How does your method affect the call stack though?

---

It is just one more function call, obviously.

Quote:

---

Originally Posted by MutantJohn

The only reason I ask is because I have recursive code that overflows the stack with calls. So today I made it iterative and not recursive.

---

That is no reason to avoid the appropriate use of functions. If necessary, use an explicit stack.

Whoa, whoa, whoa, I can use an explicit stack? How do I do that? 'Cause here's my functions, delaunay(), two_to_three().

My code goes delaunay() calls two_to_three() calls delaunay() calls two_to_three().... And this goes on for apparently, a sufficiently large amount. How do I manually allocate a call stack?

Well, you need to figure out what data needs to be saved so you can create stacks of the appropriate type(s). So, you have this code that does the stuff in delaunay. When you need to do the stuff that is currently in two_to_three (or when you need to call delaunay in two_to_three), you save the data required for delaunay in its stack. At some point, you will reach what was the base case for the recursion, upon which you pop from the appropriate stack and do whatever processing is left to do, then pop from the other stack, etc.

Quote:

---

Originally Posted by anduril462

Hmm...not the worst use of a goto, but probably not the best either. There have been times that I really wish C supported labeled break/continue statements, but that's becoming rare. I am more than happy to simply move stuff into helper functions:

Code:

---

for (auto it = vec.begin(); it < vec.end(); ) {
    process_vector_elements()
}
...
void process_vector_elements()
{
    for (int i = 0; i < 4; ++i) {  // use pre-increment in C++
        if (t[i]) {
            switch (x) {
                case 23:
                    return;

---

When it hits that return, and process_vector_elements is done, the vector loop will proceed to the next element.

As for the pre-increment, it avoids having to call a copy constructor (since it doesn't have to save the old value of i).

The other nice thing about splitting up your function like this is you've separated the processing of a vector of objects, from the processing of a single object. That keeps your code loosely coupled and makes it easier to do things like unit test your code, since you have isolated the processing of a single foo object. And it will keep your code (or at least this part of it) goto-free.

Also, I hope you're not using magic numbers (4 and 23) in the real code. Some #defines and enums would do nicely here.

Last note:
This definitely seems to be C++. I'm not much of a C++ expert, but I can't recall ever seeing a good use of goto in C++. In C, however, the most common use that I've seen (and personally the only one I generally think is a good use of goto) is for error handling, so you can avoid deeply-nested if statements or repeating tedious cleanup code.

---

I don't get it. 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)? It's really very simple:

Code:

---

    for( ;; )
        for( ;; )
            goto done;
    done:;

---

Or even:

Code:

---

    try
    {
        for( ;; )
            for( ;; )
                throw 1;
    }
    catch( int )
    {    }

---

Quote:

---

Originally Posted by laserlight

Well, you need to figure out what data needs to be saved so you can create stacks of the appropriate type(s). So, you have this code that does the stuff in delaunay. When you need to do the stuff that is currently in two_to_three (or when you need to call delaunay in two_to_three), you save the data required for delaunay in its stack. At some point, you will reach what was the base case for the recursion, upon which you pop from the appropriate stack and do whatever processing is left to do, then pop from the other stack, etc.

---

Okay, I'ma describe my code in more detail and hopefully you can help me figure this out. Or someone else can.

The idea is, I'm taking a stack of tetrahedrons and testing them. When one fails, I have to remove it and add a few more to the stack. Hence the two_to_three. I erase 2 and stack 3 more. This can happen a lot.

I don't know if stacks and recursion are the way to do this though. I spent this afternoon replacing the recursion with iteration and so far, my code seems to be behaving stably even though my treewalk is encountering some interesting errors for really high particle counts (32^3 vertices being triangulated).

I'll think about it but iteration seems kind of like the way to go.

Quote:

---

Originally Posted by Sebastiani

I don't get it. 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)?

---

Yes, you don't get it. I'm not breaking it up in a completely unnatural way. In fact, it's a very natural way to break up the code, along an "object boundary". Allow myself to quote myself:

Quote:

---

Originally Posted by anduril462

The other nice thing about splitting up your function like this is you've separated the processing of a vector of objects, from the processing of a single object. That keeps your code loosely coupled and makes it easier to do things like unit test your code, since you have isolated the processing of a single foo object. And it will keep your code (or at least this part of it) goto-free.

---

That is probably the most important point I made in my post. Decoupling your code like that is a fundamental component of good software design. Such design choices become more important as you work on larger and larger projects. Tight coupling makes it more difficult to test and debug your code, and reason about it, since you must consider the whole, tightly-coupled mess of code, instead of small, self-contained bits of code.

Quote:

---

Originally Posted by Sebastiani

It's really very simple:

Code:

---

    for( ;; )
        for( ;; )
            goto done;
    done:;

---

---

Yep. It's so simple, even I can figure out how to use goto in places I don't need to (and shouldn't) use it.

Quote:

---

Originally Posted by Sebastiani

Or even:

Code:

---

    try
    {
        for( ;; )
            for( ;; )
                throw 1;
    }
    catch( int )
    {    }

---

---

Now, that didn't occur to me. But to be fair, I did profess my lack of C++ expertise. It still, however, maintains unnecessarily tight coupling between the object itself and the list of objects.

Quote:

---

Sorry, I just felt like sharing. goto's are actually pretty sweet. I'm going to needlessly fill my code with them from now on.

---

O_o

I get that this is hyperbole, but you managed your first `goto' in a language with scoped destruction and real world compilers that don't always follow the standard.

Now, I'm not saying this will cause you problems here (The chosen example is fixed construct really so no different than `break'.), but pretty much every compiler I've ever worked on has produced invalid code on complicated `goto' and similar constructs.

To be clear, the standard specifically mandates that destructors be called however execution leaves a block, but with calculated `goto', or functionality that is otherwise problematic to statically analyze, most compilers aren't perfect.

As usual when this comes, my absurdly broad experience with breaking compilers, I am only making you aware of the potential issue you may wish to avoid on the off chance as the situation I reference is despicably hard to debug.

Quote:

---

The only reason I ask is because I have recursive code that overflows the stack with calls. So today I made it iterative and not recursive.

---

Well, you've already made it iterative, and, as I infer from the example, the major iteration is broken over partial iteration.

Your problem is literally already solved; you only need to massage the partial iteration into a consumable form.

You could use a dumb `continue' function, but I'd recommend continuing with the iterator pattern:

Code:

---

typedef /* whatever */ elem;
// ...
bool yield(elem)
{
    switch(elem)
    {
        /* partial logic */
        case 23: return false;
        // ...
    }
}
// ...
for(/*major*/)
{
    partial<elem> inner(it, vec.end(), yield)
    partial<elem> end;
    // ...
    while(inner < end) 
    {
        // ...
        // use *inner as it[i]
        // ...
    }
}
// ...

---

Of course, to me nothing is more natural than processing collections iteratively; your mileage may vary.

The idea would be the same without employing the iterator pattern so heavily:

Code:

---

typedef /* whatever */ elem;
// ...
bool continue(partial & it, partial end, int & counter)
{
    switch(/* *it[counter] */)
    {
        /* partial logic */
        case 23: return false;
        // ...
    }
}
// ...
for(/*major*/)
{
    int counter(0);
    while(continue(it, end, counter)) 
    {
        // ...
        if(valid(it))
        {
            // whatever
        }
        else
        {
            // remove from/insert into vec at it [two_to_three(it, end)];
            // or whatever again using iterators from the partial process
        }
        // ...
    }
}
// ...

---

[Edit]
Yes, I realize `continue' is a keyword; I chose it for the sake the familiar meaning not suggesting this is actual code.
[/Edit]

These are just examples of course, but crucially to the concept, you would not have "resorted to breaking up a loop in a completely unnatural way"; the core of the suggestion is breaking up the loop into the basic components of, in this case partial, iteration: increment and access.

The incrementing logic isn't just your `++'; the logic of iteration is bent by the conditions `i<4' and `it < vec.end()' so these conditions necessarily change the nature of the `continue' function.

Thanks to the dance of incrementing your access remains normal and trivial: `*it'.

Obviously, because you process the collection as a collection over major iteration, the partial processes, for example, deciding what three tetrahedrons to add, so returning a set of tetrahedrons, is a process treated as a separate component of processing the collection without managing the collection.

To be clear, no one has suggested arbitrarily breaking your code up into functions and passing around every stack variable as a reference. The goal isn't to do exactly what you've done in a different way; you must refactor, rewrite, the code so that the objects belonging to the collection are "fed", as necessary, into several district components each operating on as few as necessary tetrahedrons from the collection to do the job while the major loop drives how the functions are "fed" and what to do with the results.

I hesitate to call this a "state machine", but the label isn't far off.

Code:

---

try
{
    for( ;; )
        for( ;; )
            throw 1;
}
catch( int )
{    }

---

This example should never have been suggested.

@MutantJohn: I promise you, you would be fired for writing that C++ at any of the places I've worked.

Soma

Now I'm just sad...

Quote:

---

Originally Posted by anduril462

Yep. It's so simple, even I can figure out how to use goto in places I don't need to (and shouldn't) use it.

---

And why exactly is that?

Quote:

---

Originally Posted by phantomotap

This example should never have been suggested.

@MutantJohn: I promise you, you would be fired for writing that C++ at any of the places I've worked.

---

Please do enlighten me, O' self-righteous one.

Quote:

---

Please do enlighten me, O' self-righteous one.

---

O_o

I've already told you.

(See the time you attempted to transform exceptions into references to be conditionally checked for "nullness".)

In short, you are using the exception mechanism poorly while making the code more complicated for absolutely no reason without meaningfully changing the problem of perception you are attempting to correct.

Soma

Quote:

---

Originally Posted by phantomotap

O_o

I've already told you.

(See the time you attempted to transform exceptions into references to be conditionally checked for "nullness".)

In short, you are using the exception mechanism poorly while making the code more complicated for absolutely no reason without meaningfully changing the problem of perception you are attempting to correct.

Soma

---

I think you're mixing up my "null reference" and "unchecked return value throws exception" experiments. In any case, I don't see how throwing an exception is such a "poor" choice. Exceptions make great control flow constructs.

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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?

Well, if my code is harder to understand, it's literally because I have no idea what I'm doing XD

Quote:

---

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

Quote:

---

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

Quote:

---

Originally Posted by MutantJohn

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.

---

I think we're all in agreement that you'd be better off without the goto.

Quote:

---

Originally Posted by MutantJohn

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.

---

Yes, it was a simple solution. Treat it as a proof-of-concept. You know you can do this iteratively. Now, refactor to make your iterative approach even better.

Quote:

---

Originally Posted by MutantJohn

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.

---

Don't make the assumption that "compiles" means it "works". Even if it compiles with no errors or warnings on the strictest settings, with -pedantic. Take for example, code that compiles cleanly, but has a null pointer bug. When you compile with the -pedantic flag, it is telling the compiler to check the source code for strict ISO compliance: does it adhere to all the rules on source code, and does it avoid the use of any extensions. Nobody is saying that what you wrote, the C++ source code, isn't ISO compliant. What phantom is saying is that, under some complex uses of goto, the compiler will turn your syntactically valid C++ code into machine code that doesn't quite behave the way it ought to (specifically in properly calling the destructors of objects that fall out of scope when the goto is executed). Basically, the compiler tries to do the right thing, but doing the right thing in that case is difficult, and most compilers do it wrong. Consider it a bug in the compiler.

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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.

Ooooookay.

I like this quote the most from andy :

Quote:

---

Yes, it was a simple solution. Treat it as a proof-of-concept. You know you can do this iteratively. Now, refactor to make your iterative approach even better.

---

I will re-do my code. I was wondering if I even could translate it iteratively and I'm thrilled that it works.

Thank you all for your constructive advice.

Not gonna lie, it's kind of a lot to take at once. Between this and the resume thread, it looks like I have my work cut out for me. I think I wanna do this. I really think I do. Sorry, telling me that I'll be instantly fired does NOT help me. It just scares me and makes me feel bad. I felt threatened and like I was being dismissed. You may not believe it, but it's tough making up for all the years I wasn't taking computer science when I should've.

But I didn't count on loving programming as much as I do. I went to college thinking that I loved physics and I really do/did. I love E&M and QM is awesome. But I didn't have the drive to study for the physics GRE as well as I should've and when I started to read about how simulations worked, it opened up this whole world.

So I never took as much CS as I should've (just lower division stuff) so for me, this is all intimidating and scary. 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.

And that goes for all you others to. You're basically my education, even if you're not employed as programmers. You're all better than me and I thank you for your advice and guidance. It's very humbling and I know that learning to do things the right way is better for me in the long run and that if I truly have the discipline and pride, I will not use a goto.

Now, I gotta focus on getting a j.o.b. which will most likely be data entry/analysis for the time being. Also, can you believe I was told I didn't have enough experience to be a dishwasher? What a world we live in today.

Quote:

---

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

Quote:

---

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)

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

Originally Posted by laserlight

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

---

Sure, when C++ was conceived, I imagine the only thing Stroustrup had in mind was error propagation. An extension of existing concepts drawn from software and hardware facilities of the time. So what? For me it is a tool that can achieve many interesting and useful things and so I use it as such. A bird's feather, after all, was not "designed" to be a writing instrument and yet it was nonetheless adapted to do so. Nothing on this earth in fact would have found utility had someone not stood up one day and said "I know - I'll use it for this!". Sorry to wax philosophical, but for me the subject is just that.

Quote:

---

Originally Posted by laserlight

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.

---

In "most" cases, perhaps, but certainly not all. Checking a flag repeatedly within a loop or calling a bunch of "structured" functions may well be less efficient at times.

Obviously I am playing a bit of the devil's advocate here. For the most part I think my code, by virtue, "tends toward the convention". I just want to make it clear that I do not subscribe to nor promote any sort of "idiomatic usage for the sake of convention" type approach to programming. The mathematical beauty of a well written program transcends and trumps that any day.

to me, this seems like an appropriate situation for a lambda, if C++11 is available.

Code:

---

for (;;)
{
    [&]()
    {
        for(;;)
        {
            switch(some_variable)
            {
                case 23:
                {
                    return;
                }
            }
        }
    }();
}

---

I think it's pretty likely that, in this situation, the compiler will optimize the call/return away, and won't bring you any closer to overflowing your stack.

Quote:

---

Originally Posted by Sebastiani

For me it is a tool that can achieve many interesting and useful things and so I use it as such. A bird's feather, after all, was not "designed" to be a writing instrument and yet it was nonetheless adapted to do so. Nothing on this earth in fact would have found utility had someone not stood up one day and said "I know - I'll use it for this!". Sorry to wax philosophical, but for me the subject is just that.

---

Would you also use a while loop where an if statement is appropriate? Would you use an if statement with a label and goto if a while loop was appropriate?

I have already noted two instances of creative uses of C++ constructs that I find acceptable (template metaprogramming and Boost.Spirit's approximation of EBNF), so it should be obvious that I am in agreement that just because something was not designed to do a job doesn't mean that it cannot be used well for that job. However, when it comes to ordinary flow control, exceptions are not the best tool for the job (and you even gave a like to yet another alternative proposed, though it is along the same lines as what was suggested), hence fitting them into that role is at best creativity for the sake of it rather than to actually arrive at an elegant, efficient and maintainable solution.

Quote:

---

Originally Posted by Sebastiani

I just want to make it clear that I do not subscribe to nor promote any sort of "idiomatic usage for the sake of convention" type approach to programming.

---

Neither do I. I subscribe to idiomatic/conventional usage for the sake of code that will be easily understood. Convention is not a worthy end in itself.

Quote:

---

Originally Posted by Sebastiani

The mathematical beauty of a well written program transcends and trumps that any day.

---

Agreed. I find no mathematical beauty in abusing exceptions for ordinary flow control.

Elkvis, you're God **** right C++11 is available! I've been waiting to find a use for lambda functions ever since Elysia mentioned them awhile ago when I first posted the link to my whole project on the C++ board. Or was it you who suggest a lambda, Elkvis? I think it might've been you. Well, either you or Elysia.