Re: Breaking from the middle of a loop (C++)
"Alf P. Steinbach" <alfps@start.no> wrote:
Note: this article is cross-posted to [comp.lang.c++] and
[comp.programming].
The subject of how to best express a logical "loop-and-a-half" has
popped up in a number of recent [clc++] threads.
The language, C++, is a bit important because in C++ all code must be
prepared for exceptions at any point, so that in this language the
possibility of missed cleanup due to early exit is not an issue.
Assume helpers
void throwX( char const s[] ) { throw std::runtime_error( s ); }
string commandStringFromUser()
{
using namespace std;
string line;
cout << "Command? ";
if( !getline( cin, line ) ) { throwX( "i/o failure" ); }
return line;
}
bool isValidCommandString( string const& s )
{
return (s.length() == 1 && isValidCommandChar( s[1] ));
}
Then, an example of "loop-and-a-half" expressed with exit in the middle:
// Variant 1, exit in middle.
char validUserCommand()
{
for( ;; )
{
std::string const line = commandStringFromUser();
if( isValidCommandString( line ) )
{
return line[1];
}
giveShortHelpAboutValidCommands();
}
}
Example of expressing the loop with redundant duplication of code:
// Variant 2, unrolled.
char validUserCommand()
{
std::string line;
line = commandStringFromUser();
while( !isValidCommandString( line ) )
{
giveShortHelpAboutValidCommands();
line = commandStringFromUser();
}
return line[1];
}
Example of expressing the loop with side-effect in the condition checking:
// Variant 3, side-effect in continuation condition checking.
char validUserCommand()
{
std::string line;
while( !isValidCommandString( line = commandStringFromUser() ) )
{
giveShortHelpAboutValidCommands();
}
return line[1];
}
It has been argued that the last two forms have a loop invariant whereas
the exit-in-middle lacks one, or more specifically, that its loop
invariant isn't established until halfway through the first iteration.
I think that's a bogus argument, and prefer variant 1, exit-in-middle.
There is a long history in both C and C++ of a "single-entry, multiple
exit" style of programming, whether the extra exits are return, break,
or sometimes even goto statements.
I personally don't like the style. Yes, I have read the rational from
several authors but that isn't why I have a problem with it. My feelings
about it were born out of the times I have spent debugging other
people's code. People who used such multiple exits almost
indiscriminately. It became a truism for me that when I needed to find a
bug, the first place I would look is inside blocks of code that had
multiple exits.
Of course C++'s exception system has practically canonized the multiple
exit style. Even if I have no wish to program in that style, a library
provider can force it on me so I have to always be prepared... Several
prominent authors in the C++ community have commented on the difficulty
of writing code that is correct in the face of exceptions. It seems to
be quite a big stumbling block.
I tend to favor something like variant 2 above, avoiding both
conditionals with side-effects and premature exits from blocks of code.
I am in such a habit of using that particular variant that my functions
usually have a variable labeled "result" and take on a characteristic:
T func() {
T result = default;
// computation
return result;
}