From: Dave Harris on
leigh(a)i42.co.uk (Leigh Johnston) wrote (abridged):
> > Why not use break instead? Does the same thing, spares you from
> > having to define a label.
> >
>
> Because break only breaks out of the innermost loop, using goto to
> break out of nested loops is one of the few sensible uses of goto.

If you can't use return either, then it sounds like you have a function
which has a loop, then another nested loop, and then a bit more code
outside of both loops. At some point you have to wonder whether the
function is doing too many different things.

For example, instead of:

void process( char *filename ) {
if (FILE *fp = fopen( filename, "w" )) {
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (i == 5 && j == 5)
goto doubleBreak;
fprintf( fp, "%d %d", i, j );
}
}
doubleBreak:
fclose( fp );
}
}

use two functions:

void process( char *filename ) {
if (FILE *fp = fopen( filename, "w" )) {
process2( fp );
fclose( fp );
}
}

void process2( FILE *fp ) {
for (int i = 0; i < 10; ++i) {
for (int j = 0; j < 10; ++j) {
if (i == 5 && j == 5)
return;
fprintf( fp, "%d %d", i, j );
}
}
}

Here the first function handles opening and closing the file, and the
second one handles the actual output logic. This is a clean division of
responsibilities. The functions show a lot of cohesion. It's good to get
the fclose() in the same function as fopen() so we can be sure they pair
up correctly. The second function doesn't care about filenames, so it
could also be used with stdout or anything else the FILE abstraction can
write to. Because it doesn't need to clean up the file, it can use a
simple return statement.

In most cases, needing a goto is a sign a function is trying to do too
many things that lack cohesion. This can be true even if the function is
only 8 lines long. It's often a good idea to separate "acquiring a
resource" from "using a resource".

-- Dave Harris, Nottingham, UK.
From: James Van Buskirk on
"Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message
news:aab23e01-b4d4-44c4-a136-a619da00a3f7(a)m24g2000prc.googlegroups.com...

> I wish there were distinct breaks for loops and switches as well as
> multi-level breaks for nested loops. goto's at times are the least
> evil since they don't require you to implement extra variables to
> break out of nested loops and they help to simplify function cleanup
> code (where resources are being freed on various conditions).

Amusing that Fortran has a mechanism to break out of nested loops
and permits one to use internal subroutines for function cleanup,
not to mention no fall-through in SELECT CASE constructs. These uses
of goto are simply artifacts of the limitations of C-style languages.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: Alexei A. Frounze on
On Apr 25, 6:56 am, Patricia Shanahan <p...(a)acm.org> wrote:
> Alexei A. Frounze wrote:
>
> ...> Surprisingly, my code is pretty clean with gotos, which, btw, I use
> > just for almost exclusively 2 things:
> > - breaking out of nested loops (not always, if I can do that w/o
> > writing more than two lines of code, I don't use goto)
> > - jumping to the common cleanup code at the end of the function when I
> > detect some error
>
> ...
>
> When I was first considering using Java for a project, I was a little
> worried about the lack of goto.
>
> I knew I had written a couple of gotos in C and maintained code
> containing goto that would have had to be much more convoluted without
> it. When I analyzed those uses of goto, I realized they were all in
> those two categories, mainly the common cleanup code case.
>
> That meant I would not need goto in a language with try-finally and
> named loop break.
>
> Patricia

Of course, you could do that. And even if it was plain C but with
removed goto, you'd still be able to do your work.

Alex
From: Alexei A. Frounze on
On Apr 25, 8:52 am, Nick <3-nos...(a)temporary-address.org.uk> wrote:
> "Alexei A. Frounze" <alexfrun...(a)gmail.com> writes:
>
> > Surprisingly, my code is pretty clean with gotos, which, btw, I use
> > just for almost exclusively 2 things:
> > - breaking out of nested loops (not always, if I can do that w/o
> > writing more than two lines of code, I don't use goto)
> > - jumping to the common cleanup code at the end of the function when I
> > detect some error
> > I get by without goto in almost all other situations. I don't see
> > what's not natural here. It's a clearly written and structured code,
> > that is easy to follow, without surprises, without bloat. Of course,
> > if you never need to do any cleanup or you never check error
> > conditions or rely heavily on C++ exceptions, the 2nd use may be just
> > unnatural to you as it is to me since I'm programming C, mixed C and C+
> > + and I often have to deal explicitly with resource allocation.
>
> I've just looked at my pile of code and there are no actual gotos in
> there (there is a setjmp/longjmp pair, and a fair smattering of breaks,
> continues and returns from part way through functions).
>
> There seems to be a fairly common situation when you are programming,
> particularly in C where you have to do a lot of stuff yourself, that
> there isn't a "nice" way to deal with.  This is when you have 3 or 4
> lines of code that need to be executed under conditional circumstances
> and in different but related places.
>
> Making them into functions makes reading the code harder, and they don't
> really make sense as a conceptual chunk of code.  Embedding them in the
> code can lead to convoluted flow control - and it's here that goto and
> various other tricks tend to get invoked.
>
> The clean-up example is a common one, but it's not the only one.
>
> Just today I found myself in such a situation where I had two such
> blocks which, depending on a couple of conditions, I wanted to execute
> one, the other, or both in both orders - right in the middle of a large
> function.  So putting the code in functions several pages away from
> where they were needed wasn't nice, and short of jumping around (either
> with a loop even though there is only a single pass, or with goto) the
> only other solution is to replicate the code.
>
> In the end I compromised and with a bit of playing around was able to
> reduce the shorter to a single line of fairly straightforward code, so
> didn't mind repeating it inside conditionals either side of the larger
> one.  Still not a perfect solution of course.
> --
> Online waterways route planner            |http://canalplan.eu
> Plan trips, see photos, check facilities  |http://canalplan.org.uk

I don't know if this would work or not for your specific case, but if
blocks are sufficiently large and it's exactly one or both in either
order in the same place, then you could theoretically do something
like this:

#include <stdio.h>
int main(void)
{
const int ss[4][2] =
{
{ 1, 1 },
{ 2, 2 },
{ 1, 2 },
{ 2, 1 }
};
int i, cnt, start, stop, var;

for (i = 0; i < 4; i++)
{
start = ss[i][0];
stop = ss[i][1];

for (var = start, cnt = 1 + (start != stop);
cnt--;
var += (stop >= start) ? 1 : -1)
{
if (var == 1) printf("block 1 ");
else if (var == 2) printf("block 2 ");
}
printf("\n");
}

return 0;
}

Alex
From: Patricia Shanahan on
Alexei A. Frounze wrote:
> On Apr 25, 6:56 am, Patricia Shanahan <p...(a)acm.org> wrote:
>> Alexei A. Frounze wrote:
>>
>> ...> Surprisingly, my code is pretty clean with gotos, which, btw, I use
>>> just for almost exclusively 2 things:
>>> - breaking out of nested loops (not always, if I can do that w/o
>>> writing more than two lines of code, I don't use goto)
>>> - jumping to the common cleanup code at the end of the function when I
>>> detect some error
>> ...
>>
>> When I was first considering using Java for a project, I was a little
>> worried about the lack of goto.
>>
>> I knew I had written a couple of gotos in C and maintained code
>> containing goto that would have had to be much more convoluted without
>> it. When I analyzed those uses of goto, I realized they were all in
>> those two categories, mainly the common cleanup code case.
>>
>> That meant I would not need goto in a language with try-finally and
>> named loop break.
>>
>> Patricia
>
> Of course, you could do that. And even if it was plain C but with
> removed goto, you'd still be able to do your work.

That depends on the definition of "do your work". C with goto removed
would remain Turing-complete. The issue is one of clarity and simplicity
of the code.

Patricia