问题
I found the following code in a C program:
while (1)
{
do_something();
if (was_an_error()) break;
do_something_else();
if (was_an_error()) break;
[...]
break;
}
[cleanup code]
Here while(1) is used as local emulation of "finally". You can also write this using gotos:
do_something()
if (was_an_error()) goto out;
do_something_else()
if (was_an_error()) goto out;
[...]
out:
[cleanup code]
I thought the goto solution is a usual idiom. I have seen several occurrences of this idiom in the kernel sources and it is also mentioned in Diomidis Spinellis' "Code Reading" book.
My question is: What solution is better? Is there any specific reason to use the while(1) solution?
Question 943826 doesn't answer my question.
回答1:
The seemingly universal revultion to GOTO is largely due to Edsger Dijkstra's letter "Go To Statement Considered Harmful".
If you are determined not to use goto, something like
do {
...
while(0);
is probably safer than while(1) { ... } since it guarantees that you will not inadvertently loop (and if you are inadvertently looping, with while(1) you are probably inadvertently looping infinitely).
The one advantage that (ab)using do/break/while or while/break for this purpose has over goto is that you are guaranteed not to be jumping above the construct -- goto can be used to jump to a label earlier within the same function.
The disadvantage that do/break/while etc. have over goto is that you are limited to one exit point (immediately after the loop). In some cases you might need a staged cleanup: e.g., when you open a file handle, malloc some memory, read from the file... if the read fails, you need to clean up the malloc. If the malloc fails, you don't need to clean it up, but you still need to clean up the file handle. With goto, you can have one label per stage of cleanup and jump to precisely the right point depending on where your error occurred.
In my opinion blindly avoiding GOTO because of the prevalent hatred of it is more damaging than carefully reasoning out a case for its use on a case-by-case basis. A rule of thumb I use is "does the Linux kernel do it? If so, it can't be that bad". Substitute linux kernel with any other good example of modern software engineering.
回答2:
Putting the code into a separate function, and using return to exit early is another way to do it, with the benefit of easy integration of a return code indicating the nature of the failure.
回答3:
I know my style isn't the coolest possible, but I prefer it because it doesn't need any special constructs and is concise and not too hard to understand:
error = (!error) && do_something1(); error = (!error) && do_something2(); error = (!error) && do_something3(); // Cleanup code
回答4:
Though the use of goto is discouraged usually, some rare situations like yours is a place where best-practices are not the best.
So, if goto makes the clearest code I would use it. using a while(true) loop to emulate goto is something unnatural. What you really need is a goto!
回答5:
Why not use a series of if statements? I usually write it this way, as I find it much clearer than a loop:
bool ok = true;
do_something();
if (was_an_error()) ok = false;
if (ok)
{
do_something_else();
if (was_an_error()) ok = false;
}
if (ok)
{
do_something_else_again();
if (was_an_error()) ok = false;
}
[...]
[Cleanup code]
Also if you are working to strict coding standards, yes goto is likely to be forbidden, but often so are break and continue so the loop is not necessarily a workaround for that.
回答6:
"break" understands the semantics of the block scope, while "goto" is oblivious to it. In other words, "while-break" can be translated into functional languages like Lisp with tail-recursion, "goto" cannot.
回答7:
Normally, GOTOs are considered bad but at some places where there are only Forward Jumps through GOTOs, they are not AS bad. People avoid GOTO like plague but a well-thought-out use of GOTO is sometimes a better solution IMHO.
回答8:
I think that this use (for resource management) of goto is ok.
回答9:
Use it if you can't use goto for whatever reason
- forbidden in your project's conventions
- forbidden by your lint tool
I also think that is also one of the cases where macros aren't evil:
#define DO_ONCE for (int _once_dummy = 0; _once_dummy < 1; _once_dummy++)
回答10:
I like the while(1) approach. I use it myself. Especially, when the loop might get repeated by continue, e.g. when an element is processed inside such loop, and it's done in multiple approaches.
回答11:
Never use a condition loop with a permanently true condition. Since the condition is always true, why use a conditional loop?
Permanently true conditions are most directly represented by a goto.
回答12:
While using "goto" for error handling situations is fairly common, I'd still prefer the "while" solution (or "do while"). In the "goto" case, there are far fewer things that the compiler can guarantee. If you make a typo in the label name, the compiler can't help you there. If someone uses another goto to another label in that block, there's a good chance the cleanup code won't get called. When you use the more structured flow control constructs you are always guaranteed which code will run once the loop is over.
回答13:
"do while" and "goto out" are different on these area:
1.local variable initialization
void foo(bool t = false)
{
if (t)
{
goto DONE;
}
int a = 10; // error : Goto bypass local variable's initialization
cout << "a=" << a << "\n";
DONE:
}
It is fine to initialize in-place local variables in do ... while(0) block.
void bar(bool t = false)
{
do{
if (t)
{
break;
}
int a = 10; // fine
cout << "a=" << a << "\n";
} while (0);
}
2 difference for Macros. "do while" is a slight better. "goto DONE" in a Macro is so not the case. If the exit code is more complicated, let see like this:
err = some_func(...);
if (err)
{
register_err(err, __LINE__, __FUNC__);
#if defined (_DEBUG)
do_some_debug(err)
#endif
break;
}
and you write this code again and again, you will probably put them into a Macro.
#define QUIT_IF(err) \
if (err) \
{ \
register_err(err, __LINE__, __FUNC__); \
DO_SOME_DEBUG(err) \
break; // awful to put break in macro, but even worse to put "goto DONE" in macro. \
}
And the code become:
do
{
initial();
do
{
err = do_step1();
QUIT_IF(err);
err = do_step2();
QUIT_IF(err);
err = do_step3();
QUIT_IF(err);
....
} while (0);
if (err) { // harder for "goto DONE" to get here while still using macro.
err = do_something_else();
}
QUIT_IF(err);
.....
} while (0);
3.do... while(0) handles different levels of exiting with same macro. Code is shown above. goto ... is not the case for Macro cause you need different labels for different levels.
By saying that, I do not like both of them. I'd prefer to use the exception method. If exception is not allowed, then I use "do ... while(0)", since the whole block is indented, it is actually easier to read than "goto DONE" style.
来源：https://stackoverflow.com/questions/1073397/while1-break-instead-of-goto