- #1
bomba923
- 763
- 0
Some find it alright if it simplifies code, while others deem it absolutely unacceptable.
So what's the general consensus regarding their use?
So what's the general consensus regarding their use?
Last edited:
Burnsys said:my boss use lots of goto and his code is unreadable !
If you are working in a team, or your code will be read by someone else, avoid using it.
for(p = 2; p*p <= N; ++p) {
if(N % p == 0) { goto found_factor; }
}
printf("N is prime!");
found_factor:
// continue along
I was trying to be funny - to avoid the simple "goto error:" in the middle of a complex loop we now have exceptions which are exactly the same thing only more confusing.D H said:Not all languages support exceptions, and not all projects allow their use.
mgb_phys said:I was trying to be funny - to avoid the simple "goto error:" in the middle of a complex loop we now have exceptions which are exactly the same thing only more confusing.
D H said:I see, and I agree. Wrapping a bunch of code in a try/throw/catch pile of complexity to avoid a simple and obvious "goto error",
Hurkyl said:A goto should be used whenever it makes the code easier to read!
Typically, this involves making the code most resemble the algorithm you're trying to implement. Another circumstance that hasn't been mentioned is when you have code that should only be executed when your loop finishes normally:
Code:for(p = 2; p*p <= N; ++p) { if(N % p == 0) { goto found_factor; } } printf("N is prime!"); found_factor: // continue along
(Compile-time) state machines are another good candidate for using goto's.
for(p = 2; p*p <= N; ++p) {
if(N % p == 0) { found_factor = true; break; }
}
if (!found_factor) { printf("N is prime!"); }
// continue along
void found_factor(int factor) {
printf("N is not prime, it has %d as a factor", factor);
}
for(p = 2; p*p <= N; ++p) {
if(N % p == 0) { found_factor(p); break; }
}
// continue along
mgb_phys said:These days you just use exceptions which are merely gotos with a much more complicated syntax.
nmtim said:Exception propagation in C++ does stack unwinding. I didn't think goto did that.
Real programmers use "comefrom".
jim mcnamara said:I thought real programmers used setjmp() and longjmp(). :)
for(p = 2; p*p <= N; ++p) {
if(N % p == 0) { found_factor = true; break; }
}
if (!found_factor) { printf("N is prime!"); }
else{...}
// continue along
Fortan has computed gotos, and C has pointers to functions, close enough. IBM's mainframes include an machine laungauge instruction "Execute" that adds a third register based parameter to an otherwise two parameter instruction, which is close to modifying executable code.mgb_phys said:No - real programmers modify the executable image on the fly
None of these are even close. The machine instructions offer a very, very limited sense of what mgb_phys is talking about. You have to program in Lisp or something like it to truly understand the incredible power that results when a program can literally modify itself on the fly.Jeff Reid said:Fortan has computed gotos, and C has pointers to functions, close enough. IBM's mainframes include an machine laungauge instruction "Execute" that adds a third register based parameter to an otherwise two parameter instruction, which is close to modifying executable code.mgb_phys said:No - real programmers modify the executable image on the fly
Well when the instruction cache on Intel CPU's started ignoring changes to memory that were already cached, it doomed all of the "real programmers". Back in the old days of assembly language programming on older computers, I was stuffing the address fields of jump and call instructions which was similar to Fortran's computed goto and C's pointer to functions which is why I mentioned them. When pinching cycles on old 8 bit cpu's helped, I was modding interrupt vector addresses to avoid using a modded jump and save a few cycles. Then there was the method of unfolding a loop for a routine by generating a sequence of instructions during initialization, and stuffing a return at the right spot for the loop count then restoring that spot after a call.mgb_phys said:No - real programmers modify the executable image on the fly
But like I said, it depends on the algorithm you're trying to implement. If your algorithm is most naturally stated as "find a factor, and then do other stuff", and primality is an exceptional case, then the goto best reflects the actual algorithm, and it's what I would use in my code without hesitation.CompuChip said:Which could be argued about, since the code after found_factor will still be executed after printing the "N is prime" message.
I'd write
Code:for(p = 2; p*p <= N; ++p) { if(N % p == 0) { found_factor = true; break; } } if (!found_factor) { printf("N is prime!"); } // continue along
And this is certainly wrong! This form only accommodates exceptional behavior when the loop terminates via the break, and does not allow exceptional behavior when the loop terminates normally.or, if there is more extensive code than a print, even something like
Code:void found_factor(int factor) { printf("N is not prime, it has %d as a factor", factor); } for(p = 2; p*p <= N; ++p) { if(N % p == 0) { found_factor(p); break; } } // continue along
nmtim said:Exception propagation in C++ does stack unwinding. I didn't think goto did that.
Code simplification refers to the process of streamlining and reducing the complexity of computer code. It is important because it can make code easier to understand, maintain, and debug, ultimately improving overall efficiency and productivity.
Some techniques for simplifying code include using descriptive and consistent variable names, breaking down large blocks of code into smaller functions, and removing redundant or unnecessary code.
No, code simplification is not always beneficial. In some cases, overly simplified code can lead to decreased performance or functionality. Additionally, code that is too simplified may be difficult for others to understand and may not meet the specific needs of a project.
Some potential drawbacks of code simplification include increased development time, decreased flexibility, and the potential for introducing bugs or errors. Additionally, simplifying code too much may make it less adaptable to future changes or updates.
Determining if code simplification is necessary for a project depends on several factors, including the complexity of the code, the overall goals and needs of the project, and the capabilities and resources of the development team. It is important to carefully weigh the potential benefits and drawbacks before deciding if code simplification is necessary for a specific project.