Thread: Is GOTO a bad idea ever?

  1. #31
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by KCfromNC View Post
    If the compiler decides to inline the function the generated code will look surprisingly similar to any of the the other flag or goto-based solutions to this problem. No call/return semantics needed.

    I have similar caveats for anyone using the phrase "stack variable" in their reasoning to prefer using goto, but they're more open to debate.
    yes, but in my opinion, it's better to always assume that the compiler will not inline your code. I always make the assumption that it will invoke call/return semantics, because even when you tell the compiler that it should inline a function, it's not required to do it, and in fact it's not required, nor can it be expected, to inline a particular function at any time.

  2. #32
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    945
    I think we've gone off-base with discussing how a compiler may or may not inline a function or how a compiler translates source code into machine language. The fact of the matter is that all of the structured statements (if, for, while, switch, etc) can be compiled down to "jump" or "branch" instructions, which are more or less equivalent to C's "goto" statement.

    The other fact is that it doesn't really matter how C statements are compiled into machine code (unless you're optimizing your code, which is unnecessary for probably 99% of the time). What does matter is whether the use of goto makes the source code more readable and easier to follow and understand. If it makes source code easier to understand, use it; otherwise, don't. Source code should still be written for humans to read.


    That said, I use goto only for exception handling, just as it's used in the Linux kernel (see Codeplug's comment in particular). I find that it's a lightweight method to handle error conditions (another way is to use setjmp/longjmp, but that is not so lightweight). In a language with native support for exceptions (like C++), I argue that goto is never necessary nor useful.

  3. #33
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by christop View Post
    I think we've gone off-base with discussing how a compiler may or may not inline a function or how a compiler translates source code into machine language. The fact of the matter is that all of the structured statements (if, for, while, switch, etc) can be compiled down to "jump" or "branch" instructions, which are more or less equivalent to C's "goto" statement.
    "The back plate of my watch, and a gun can both be melted down into molten metal, therefore my watch is more or less equivalent to a gun.".
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  4. #34
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by christop View Post
    In a language with native support for exceptions (like C++), I argue that goto is never necessary nor useful.
    especially now that we have lambdas that we can call inline, and return from, to break from nested loops, as I demonstrated in a previous post. I think any optimizing compiler worth its salt should probably recognize such a construct and inline it anyway.

  5. #35
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    945
    Quote Originally Posted by iMalc View Post
    "The back plate of my watch, and a gun can both be melted down into molten metal, therefore my watch is more or less equivalent to a gun.".
    I was comparing a "jump" instruction to C's "goto" statement, because they are more or less the same thing--they both divert program flow to somewhere else in the program (though C limits goto to a single function). And I stand by the logical conclusion--that the control structures are more or less equivalent to "goto" (and I mean at the machine instruction level) for the same reason--they divert program flow to somewhere else in the program (the only real difference being that the control structures are conditional).

    The main point I was making is that how C statements get melted down into machine instructions should not influence a programmer's choice in which statements or constructions to use, but rather a programmer should use whatever is easiest to understand. So I think we shouldn't be discussing the low-level stuff when deciding whether to use goto or some other construct.

    By the way, TheBigH is almost correct about function calls being goto by another name (again, at the machine level). A function call is basically saving the current program location, or rather the following program location (the "return address"), and then jumping/branching to another location (the start of the function). Most processors do have special instructions to do both of these steps in a single instruction (like "call" on x86), and there has to be a way to pass arguments to the function and to retrieve the return value from the function (which are really just operations done before and after the "call" instruction), but it's still a jump/goto. Likewise, returning from a function is basically jumping (goto'ing) the saved program location. (Some old BASIC interpreters made the similarity between goto and function calls more obvious: the GOTO and GOSUB commands were the same--they both jumped to a line number--except that GOSUB would save the next line number to a stack before jumping.)

  6. #36
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by christop View Post
    (the only real difference being that the control structures are conditional).
    the "jump" commands of most processors also have conditional variants, such as je, jne, jz, jnz, etc on x86.

    Quote Originally Posted by christop View Post
    The main point I was making is that how C statements get melted down into machine instructions should not influence a programmer's choice in which statements or constructions to use, but rather a programmer should use whatever is easiest to understand. So I think we shouldn't be discussing the low-level stuff when deciding whether to use goto or some other construct.
    agreed. the programmer should NEVER have to concern him/herself with the architecture-specific details when writing in a higher-level language. that is the point of computer languages.

    Quote Originally Posted by christop View Post
    By the way, TheBigH is almost correct about function calls being goto by another name (again, at the machine level). A function call is basically saving the current program location, or rather the following program location (the "return address"), and then jumping/branching to another location (the start of the function). Most processors do have special instructions to do both of these steps in a single instruction (like "call" on x86), and there has to be a way to pass arguments to the function and to retrieve the return value from the function (which are really just operations done before and after the "call" instruction), but it's still a jump/goto. Likewise, returning from a function is basically jumping (goto'ing) the saved program location. (Some old BASIC interpreters made the similarity between goto and function calls more obvious: the GOTO and GOSUB commands were the same--they both jumped to a line number--except that GOSUB would save the next line number to a stack before jumping.)
    yes, the concepts are similar, but there is a clear distinction, and I think that TheBigH just oversimplified it with that statement.

  7. #37
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by Elkvis View Post
    the "jump" commands of most processors also have conditional variants, such as je, jne, jz, jnz, etc on x86.
    agreed. the programmer should NEVER have to concern him/herself with the architecture-specific details when writing in a higher-level language. that is the point of computer languages.
    That's totally misguided. It's like saying drivers should never have to concern themselves with pedestrians, because that is not the point of driving.

    Your code will always be executed somewhere so you need to be aware of the limitations and benefits of the architecture it is deployed on. Theoretically, C is a high level language, at least by comparison to assembly, and you will find C code deployed on a variety of architectures with a variety of implementations that squeeze out every possible optimisation on that architecture.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  8. #38
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Quote Originally Posted by claudiu View Post
    That's totally misguided. It's like saying drivers should never have to concern themselves with pedestrians, because that is not the point of driving.
    No, that's like saying that the driver should not concern himself about the thermodynamic principles of the internal combustion engine of the car.

  9. #39
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by claudiu View Post
    Your code will always be executed somewhere so you need to be aware of the limitations and benefits of the architecture it is deployed on. Theoretically, C is a high level language, at least by comparison to assembly, and you will find C code deployed on a variety of architectures with a variety of implementations that squeeze out every possible optimisation on that architecture.
    you really just made my point. C code can be compiled and built for so many architectures, and except in the case of embedded systems, the programmer need not know the details of the hardware that will execute the code. that job is best left to the compiler and the standard or other libraries. I suspect you may be one of those "premature optimization" types. I'll bet you write inline assembly in the majority of your programs. if your specific needs require it, more power to you, but as a general rule, A C programmer should not need to know anything about hardware. that's why we have languages, libraries and standards - so that programmers can stick to the work of developing software, instead of worrying about how to squeeze a few more clock cycles out of a particular algorithm.

  10. #40
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    No, optimisations that are aware of hardware limmits are not only for embedded programming. For example, it is common for high level programmers to optimise data access into 64 byte snippets for cacheing purposes. But the use of goto is not for optimisation.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  11. #41
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by Elkvis View Post
    you really just made my point. C code can be compiled and built for so many architectures, and except in the case of embedded systems, the programmer need not know the details of the hardware that will execute the code. that job is best left to the compiler and the standard or other libraries. I suspect you may be one of those "premature optimization" types. I'll bet you write inline assembly in the majority of your programs. if your specific needs require it, more power to you, but as a general rule, A C programmer should not need to know anything about hardware. that's why we have languages, libraries and standards - so that programmers can stick to the work of developing software, instead of worrying about how to squeeze a few more clock cycles out of a particular algorithm.
    Firstly, I don't disagree with you over the fact that high level languages need to provide an adequate amount of abstraction by definition. God forbid, we would have to think through every little aspect of the architecture when programming. However, I disagree with your idea that code magically floats in the air, and the programmer needn't be concerned with anything else except writing it. No, I am not saying you should second guess compiler optimisations on a regular basis, what I am saying is that you should be opened to the idea that you may have to once in a while. Unlike you, I am not so comfortable with preaching total ignorance in this respect, but rather, a bit of prudence.

    Secondly, don't think you know anything about how I code, this is really just another ungrounded assumption.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  12. #42
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    you have misinterpreted my words, possibly deliberately.

    my statement was that a programmer does not need to understand the details of the architecture to write C code. I did not at any time suggest that one should always ignore said details. I have not in any way said that code "magically floats in the air." My statement was that pure standard-compliant C code will compile and run on any platform that has a standard-compliant compiler environment. I don't know where you got the part about magically floating in the air. you're just putting words in my mouth.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Why is goto bad?
    By DarkAlex in forum C++ Programming
    Replies: 28
    Last Post: 12-02-2007, 11:24 AM
  2. GoTo's?
    By Neo1 in forum C++ Programming
    Replies: 4
    Last Post: 07-09-2007, 03:24 AM
  3. goto
    By chrismiceli in forum C Programming
    Replies: 20
    Last Post: 08-26-2003, 07:19 AM
  4. goto again...
    By volk in forum C++ Programming
    Replies: 4
    Last Post: 04-29-2003, 07:25 PM
  5. Good idea, bad idea.
    By sean in forum A Brief History of Cprogramming.com
    Replies: 2
    Last Post: 06-15-2002, 12:26 PM

Tags for this Thread