why are GOTO's not used ...

"Malcolm McLean" <re*******@btinternet.comwrites:

"santosh" <sa*********@gmail.comwrote in message
>>
You might as well program in assembler.

That's actually quite a good technique.

Write the function in C, with the emphasis on getting it to work.

And now you're done.

Then
slowly replace the C control structures with ifs on a single variable,
eg if(flag) and gotos, to make it more and more
assembly-like. Eventually each line of C becomes one line of
assembler. Then you can code up the assembly function.

Then measure the relative performance of your original C code
(compiled with maximum optimization) vs. the performance of the
assembly code. It's not unlikely that you'll find you've wasted your
time -- especially when you have to go through the whole exercise
again if you need the program to work on a different platform.

Your method might be a good one *if* you've confirmed (by
measurement!) that a particular chunk of code is a performance
bottleneck, that you can't correct the performance problem without
resorting to assembly language, and that it's worth the cost of the
extra effort and loss of portability.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Aug 17 '08 #10

raashid bhatt <ra**********@gmail.comwrites:

why are GOTO's not used they just a simple JMP instructions what's bad
about them

There's a tremendous amount of literature about this, going back at
least to Dijstra's 1968 letter "Go To Statement Considered Harmful".

But here's my summary of why goto statements should *usually* be
avoided.

Most control flow constructs used in programs (if, if/else, for,
while, do/while, etc.) reflect concepts in the problem domain:

Do this, but only under these circumstances.
Do this under these circumstances; otherwise do that.
Do this that many times.
Repeatedly do this as long as this condition still holds.

The goto statement, on the other hand, reflects a concept in the
source code of your program:

Jump to the statement in this function with the label "FOO".

If you make the structure of your code reflect the structure of the
problem the code is trying to solve, it's easier to maintain.

Having said that, there are cases where a goto statement can be
justified -- and most of those times, it's a replacement for a control
flow construct that's missing from the language.

For example, C provides no way to break out of nested loops. A goto
statement can act as a replacement for a multi-level break.
Similarly, C doesn't provide exception handling, a way to abort
execution at a certain point and recover at a higher point; again, a
goto statement can emulate this (but only within a single function).
On the other hand, re-structuring the code is sometimes a better way
to do this. (It's been argued that multi-level breaks, and perhaps
even single-level breaks, are a bad idea anyway, and that loops should
terminate only at the bottom.)

Finally, if you're coding an explicit finite state machine, a goto
statement *can* reflect a concept in the problem domain, namely
transitioning from one state to another, where the current state is
represented by where you are in the code. (On the other hand, another
way to implement this is to use an enum variable for the state and
write a switch statement inside a loop.)

In practice, excessive use of goto statements can easily lead to
so-called "spaghetti code", in which the behavior of any piece of the
code isn't obvious until you understand *all* the code. Code without
gotos is often easier to maintain.

If you must use goto statements, it's best to have them branch only
forward in the code; this minimizes spagettification.

Like any debate about style, there are opposing viewpoints.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Aug 17 '08 #11

Flash Gordon

Keith Thompson wrote, On 17/08/08 22:52:

"Malcolm McLean" <re*******@btinternet.comwrites:
>"santosh" <sa*********@gmail.comwrote in message
>>You might as well program in assembler.

That's actually quite a good technique.

Write the function in C, with the emphasis on getting it to work.

And now you're done.

No you are not, you test and measure the performance and if it is good
enough you are done.

> Then
slowly replace the C control structures with ifs on a single variable,
eg if(flag) and gotos, to make it more and more
assembly-like. Eventually each line of C becomes one line of
assembler. Then you can code up the assembly function.

Then measure the relative performance of your original C code
(compiled with maximum optimization) vs. the performance of the
assembly code. It's not unlikely that you'll find you've wasted your
time -- especially when you have to go through the whole exercise
again if you need the program to work on a different platform.

Your method might be a good one *if* you've confirmed (by
measurement!) that a particular chunk of code is a performance
bottleneck, that you can't correct the performance problem without
resorting to assembly language, and that it's worth the cost of the
extra effort and loss of portability.

In my experience tight assembler code will look nothing like the C code
I would expect Malcolm's suggestion to produce. If it did then the
optimiser would probably have produced it! When writing highly optimised
assembler you use all sorts of little (and big) tricks which don't map
nicely on to C structures. If you don't need to produce tight assembler
then there is no point.
--
Flash Gordon

Aug 17 '08 #12

Ian Collins

santosh wrote:

Malcolm McLean wrote:

>"raashid bhatt" <ra**********@gmail.comwrote in message news:
>>why are GOTO's not used they just a simple JMP instructions what's
bad about them

Indeed. C has a perfectly functional goto statement, which will
compile to a basic assembler jump.

I note that you have failed to actually answer the OP's question.

To the OP:

It's not true to say that the goto is "not used". It's use is often
discouraged, but it's nevertheless used in some situations. Unlike
gets, goto *can* be used wisely, though in my experience, you need
quite some practise in programming before you can acquire this ability.

And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!

--
Ian Collins.

Aug 17 '08 #13

August Karlstrom

Richard Heathfield wrote:

raashid bhatt said:

>why are GOTO's not used they just a simple JMP instructions what's bad
about them

goto Try

refuse to use them at all. Then wait six months. Then go and make some
goto medium-scale

Then wait six months. Then go and make some medium-scale changes to the
goto code

medium-scale changes to the code (not cosmetic, but not drastic surgery
goto either

Now try without them. Specifically, write a large program in which you
goto refuse

code (not cosmetic, but not drastic surgery either). Consider how difficult
goto this

either). Consider how easy this is, relative to the other program.
goto end

this is.
goto Now

Try them. Specifically, write a large program in which you use them freely.
goto Then

end

Brilliant!
August
(However, in a [C] program with gotos there would be no non-terminated
statements [sentences] between the jumps)

Aug 18 '08 #14

August Karlstrom

Keith Thompson wrote:
[...]

For example, C provides no way to break out of nested loops. A goto
statement can act as a replacement for a multi-level break.
Similarly, C doesn't provide exception handling, a way to abort
execution at a certain point and recover at a higher point; again, a
goto statement can emulate this (but only within a single function).
On the other hand, re-structuring the code is sometimes a better way
to do this. (It's been argued that multi-level breaks, and perhaps
even single-level breaks, are a bad idea anyway, and that loops should
terminate only at the bottom.)

On way to restructure the code is to put the nested loops in a separate
auxiliary function and break out of the loops with a return statement, e.g.

int foo_aux();

void foo()
{
int status;

/* initialize */
/* ... */

status = foo_aux();

/* clean up */
/* ... */
}

int foo_aux()
{
...
for (...) {
for (...) {
if (some_condition) {
return 37;
}
}
}
...
return 0;
}
August

Aug 18 '08 #15

Bartc

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:NI******************************@bt.com...

raashid bhatt said:

>why are GOTO's not used they just a simple JMP instructions what's bad
about them

goto Try

....

Try them. Specifically, write a large program in which you use them
freely.
goto Then

That's a far-fetched example. Used properly, to augment existing control
structures, Goto is not such a big deal as people seem to think. Used by
code-generaters (generating C-code) it's a non-issue because the code will
never be seen or maintained.

And it's a natural control structure that many people will be familiar with,
eg. on lists of instructions and any number of forms ("If you answered No,
please proceed to question 8...").

Of course it can be abused, but so can lots of things.

--
Bartc

Aug 18 '08 #16

On Sun, 17 Aug 2008 22:25:45 UTC, Keith Thompson <ks***@mib.org>
wrote:

There is not a single case where a goto is justified.

However you needs a plan to get a maintainable program written.

A program means: resolve a problem (whatever that may be).

How to resolve the problem?

Startup by breaking down this problem in lower ones.

Mosst of the lower problems are too big to them done in a low number
of steps, so break them down in lower ones. Recurese in breaking down
the problems in lower ones until all of them are so low that only a
low number of steps is needed to get this little problem resolved.

Now you ha a hudge number of litte problem.

Start with one of them. Write a function that does resolve the
problem. Continue on that until all little problems are resolved.

Bind the little problems in they logical sequences to get the more
bigger problem solved. That means you'll write a function that call
the functions thowing how these very little probles gets resolved
together to get the bigger problem resolved. Continue for all the
problems on that level.

Recure back to the next upper level and continue with next bigger
problem until all broken down problems are resolved and the program is
complete.

You'll find that there is not a single goto is used.

But you have a sequence of do this, then that, and thereafer this
followed by that.... done!

When you looks deeper then you have that more detailed again. and on
the deepest leves you sees how it is done.

You have deep nested loops? Oh, you have them already broken down to
nested functions because you have broken down the problem in more
litte problems. So details of the solution are broken down in more
detailed soluntions. Each little solution is a sequence of steps of
the sequence to get the problem resolved. When it is more complex then
you ave a good overview and sees when interested in the details in an
own function.

As each single step can fail you'll have sometimes a strategy to get
the failed step repaired to tage it again - or fail completely. When
you fails complete you simply returns to the parent step with the
message "faild (because...)" Again: no goto in sight.

Without a plan what is why how to do you'll ends up quickly in
spaghetty code, crying for goto and other hacks, leaving unmaintable
code.

Object oriented thinking but having nothing that own brain, paper,
pencil and rubber beside a plan how to get the big problem resolved in
acceptable time by leaving a high maintable program for the following
maintainer is possible - but not when gotos are breaking the flow.

Today you will replace pencil, rubber and paper with a keyboard,
screen and a comfortable editor. You'll use an optimising compiler,
linker and make to shorten the translation phase and a debugger to
find and remove the self implemented bugs.

There were in the last 25 years not a single case to use goto. And
there will none in the future.

Before I learned C there was a time I had to program in fortran,
mumps, cobol, sicol, crisp, whereas goto was sometime unavoidable.
Between that linst I learned RTLII, a brother of C with no goto in the
syntax tree.

In the old days while I had to use assember and constructs like do,
while, for not available I had coded like like a C compiler produce
assembly today.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

Aug 18 '08 #17

rio

"santosh" <sa*********@gmail.comha scritto nel messaggio
news:g8**********@registered.motzarella.org...

Malcolm McLean wrote:

>>
"raashid bhatt" <ra**********@gmail.comwrote in message news:
>>why are GOTO's not used they just a simple JMP instructions what's
bad about them

Indeed. C has a perfectly functional goto statement, which will
compile to a basic assembler jump.

I note that you have failed to actually answer the OP's question.

To the OP:

It's not true to say that the goto is "not used". It's use is often
discouraged, but it's nevertheless used in some situations. Unlike
gets, goto *can* be used wisely, though in my experience, you need
quite some practise in programming before you can acquire this ability.
In short, goto is prone to abuse by beginners (though that's not to say
that *all* beginners abuse goto or that experienced programmers never
do so).

It's overuse tends to break up the "higher level" structure of the code
and it's flow of control making it hard to read and hard to extend. It
also throws away the intent the programmer had in coding a particular
construct which high-level statements can preserve and convey.

Just compare these two code fragments that do the same thing:

1.

1 for (i = 0; i < 10; i++) {
2 for (j = 0; j < 10; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

yes "Just compare"

1 i=0;
2 .0: j=0; /* 0,1,..9 */
3 .1: putc('*' , stdout); if(++j<10) goto .1;
4 putc('\n', stdout); if(++i<10) goto .0;

i think you have found the wrong example
the goto one doesn't seem so dark.
Possibly someone will be luck next time
for find one example where goto is inferior

2.

i = 0;
outer_loop:
if (i == 10) {
goto end_loop;
}
else {
i++;
}
j = 0;
inner_loop:
putc('*', stdout);
if (j == 10) {
putc('\n', stdout);
goto outer_loop;
}
else {
j++;
goto inner_loop;
}
end_loop:
/* proceed */

the infomous spaghetti code

You might as well program in assembler.

Aug 19 '08 #18

santosh

rio wrote:

santosh wrote:

[ goto vs. structured control flow ]

>Just compare these two code fragments that do the same thing:

1.

1 for (i = 0; i < 10; i++) {
2 for (j = 0; j < 10; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

yes "Just compare"

1 i=0;
2 .0: j=0; /* 0,1,..9 */
3 .1: putc('*' , stdout); if(++j<10) goto .1;
4 putc('\n', stdout); if(++i<10) goto .0;

i think you have found the wrong example

I think you have just confirmed my point.

the goto one doesn't seem so dark.

As I said, you might as well program in assembler or BASIC.

<snip>

the infomous spaghetti code

And what do you call your example?

<snip>

Aug 19 '08 #19

rio

"Herbert Rosenau" <os****@pc-rosenau.deha scritto nel messaggio
news:wm***************************@JUPITER.PC-ROSENAU.DE...

On Sun, 17 Aug 2008 22:25:45 UTC, Keith Thompson <ks***@mib.org>
wrote:

i think you have right in almost all
and i think you are very good on break one big problem in many
easy to resolve, much more than me, but

There is not a single case where a goto is justified.

if you say that goto is so impractical so it is a miracle
that the below routine run well and i, even if know
something of C believe, i could not write something easier
in C

i think all you miss the use of goto + indentation
is more readable of all your for() while() loops
all together

; u32 FormatA(u32* ArrOut,u32 ArrSize,u32* ArrIn)
; 0k,4j,8i,12b,16ra,
; 20PArrOut,24PArrSize,28PArrIn
FormatA:
push ebx
push esi
push edi
push ebp
mov edi, [esp+20]
mov ebp, [esp+24]
mov esi, [esp+28]
cmp edi, 0
je .e
cmp ebp, 0
jle .e
cmp esi, 0
jne .2
..e: stc
jmp .z
..1: call Copy_jki
jc .e
jmp .z
..2: call LevaSpaziDa_i
cmp eax, ';'
je .1
cmp eax, '%'
je .1
cmp eax, 13
je .1
cmp eax, 10
je .1
cmp eax, 0
je .1
mov eax, dword [esi]
mov edx, dword[esi+4]
cmp eax, "sect"
jne .3
cmp edx, "ion "
je .1
jmp short .4
..f: clc
jmp .z
..3: cmp eax, "SECT"
jne .4
cmp edx, "ION "
je .1
..4: cmp eax, "segm"
jne .3a
cmp edx, "ent "
je .1
jmp short .3b
..3a: cmp eax, "SEGM"
jne .3b
cmp edx, "ENT "
je .1
jmp short .3b
..3b: cmp eax, "resb"
jne .3c
cmp byte[esi+4], ' '
je .1
..3c: cmp eax, "resw"
jne .3d
cmp byte[esi+4], ' '
je .1
..3d: cmp eax, "resd"
jne .3e
cmp byte[esi+4], ' '
je .1
..3e: and edx, 0x00FFFFFF
cmp eax, "exte"
jne .3f
cmp edx, "rn "
je .1
..3f: cmp eax, "glob"
jne .3g
cmp edx, "al "
je .1
..3g: and eax, 0x00FFFFFF
cmp eax, "db "
je .1
cmp eax, "dd "
je .1
cmp eax, "dt "
je .1
cmp eax, "dq "
je .1
cmp eax, "dw "
je .1
cmp eax, "do "
je .1
cmp eax, "dy "
je .1
call FindEndNextWord_i
jc .e
jmp short .4b
..4a: inc edx ; dopo gli spazi
..4b: mov al, [edx]
cmp eax, 0
je .f
cmp byte[MyTable+eax], Space
je .4a
mov eax, dword [edx]
mov ebx, dword[edx+4]

cmp eax, "resb"
jne .1c
cmp byte[edx+4], ' '
je .1
..1c: cmp eax, "resw"
jne .1d
cmp byte[edx+4], ' '
je .1
..1d: cmp eax, "resd"
jne .1e
cmp byte[edx+4], ' '
je .1
..1e:
and ebx, 0x0000FFFF
cmp eax, "time"
jne .4c
cmp ebx, "s "
je .1
..4c:
and eax, 0x00FFFFFF
cmp eax, "db "
je .1
cmp eax, "dd "
je .1
cmp eax, "dt "
je .1
cmp eax, "dq "
je .1
cmp eax, "dw "
je .1
cmp eax, "do "
je .1
cmp eax, "dy "
je .1
mov ebx, 6
cmp byte[esi+ecx-1], ':'
jne .5
call PrendiWord_jki
jc .e
cmp eax, 0
je .f
sub ebx, ecx
jg .5
mov ebx, 1
..5: push ebx
call Spazi_j ; .e1: pop õ8
mov ebx, 6
call LevaSpaziDa_i
cmp eax, ";"
je .1
call PrendiWord_jki
jc .e
cmp eax, 0
je .f
sub ebx, ecx
jg .6
mov ebx, 1
..6: push ebx
call Spazi_j
..7: call LevaSpaziDa_i
cmp eax, ";"
jne .7a
..5a: mov ebx, 32
mov ecx, edi
sub ecx, [esp+20]
sub ebx, ecx
jg .6a
mov ebx, 1
..6a: push ebx
call Spazi_j
jmp .1
..7a: cmp eax, 0
je .f
cmp eax, ","
je .8
push 2
call Spazi_j
jc .e
..8: call PrendiWord_jki
jc .e
cmp eax, 0
je .f
cmp byte[edi-1], ';'
jne .9
mov byte[edi-1], 0
dec edi
dec esi
jmp short .5a
..9: jmp short .7
..z:
pop ebp
pop edi
pop esi
pop ebx
ret 12

; parametri: i la stringa da leggere
; j la stringa da scrivere
; k la size di j
; alla fine modifica sia i,j,k
; Ritorna in ecx la lunghezza della parola
; scritta in j
;
; il primo carattere puntato da i
; non deve essere spazio
; modifica i,j,k,a,c
PrendiWordTraSpazi_jki:
push ebp
xor eax, eax
cmp ebp, 0
jl .e
jz .ee
jmp short .1
..ee: mov ecx, [esp]
sub ecx, ebp
mov byte [edi], 0
..e: stc
jmp short .z
..0: dec ebp
jz .ee
inc esi
inc edi
cmp eax, ','
je .2
cmp eax, ';'
je .2
..1: mov al, [esi]
mov [edi], al
cmp eax, 0
je .3
cmp byte[MyTable+eax], Space
jne .0
..2: mov byte [edi], 0
..3: mov ecx, [esp]
sub ecx, ebp
clc
..z:
lea esp, [esp+4]
ret

----------------------------------------------------
/* u32 FormatA(u32* ArrOut,u32 ArrSize,u32* ArrIn)
/* 0k,4j,8i,12b,16ra,
/* 20PArrOut,24PArrSize,28PArrIn
FormatA:
<b,i,j,k
j=[s+20]|k=[s+24]|i=[s+28]
j==0#.e |k<=0?#.e|i#.2
..e: stc| ##.z
..1: Copy_jki()|jc .e |##.z
..2: LevaSpaziDa_i()
a==';','%',13,10,0#.1
a=D*i| r=D[i+4]
a=="sect"!#.3| r=="ion "#.1|#.4
..f: clc| ##.z
..3: a=="SECT"!#.4 | r=="ION "#.1
..4: a=="segm"!#.3a| r=="ent "#.1|#.3b
..3a: a=="SEGM"!#.3b| r=="ENT "#.1|#.3b
..3b: a=="resb"!#.3c| B[i+4]==' '#.1
..3c: a=="resw"!#.3d| B[i+4]==' '#.1
..3d: a=="resd"!#.3e| B[i+4]==' '#.1
..3e: r&=0x00FFFFFF
a=="exte"!#.3f| r=="rn "#.1
..3f: a=="glob"!#.3g| r=="al "#.1
..3g: a&=0x00FFFFFF
a=="db ","dd ","dt ", "dq "#.1
a=="dw ","do ","dy "#.1
FindEndNextWord_i()
jc .e| #.4b
..4a: ++r /* dopo gli spazi
..4b: al=*r|a==0#.f
B[MyTable+a]==Space#.4a
a=D*r| b=D[r+4]

a=="resb"!#.1c| B[r+4]==' '#.1
..1c: a=="resw"!#.1d| B[r+4]==' '#.1
..1d: a=="resd"!#.1e| B[r+4]==' '#.1
..1e:
b&=0x0000FFFF
a=="time"!#.4c|b=="s "#.1
..4c:
a&=0x00FFFFFF
a=="db ","dd ","dt ", "dq "#.1
a=="dw ","do ","dy "#.1
b=6
B[i+c-1]==':'!#.5
PrendiWord_jki()
jc .e|a==0#.f
b-=c|>?#.5|b=1
..5: Spazi_j(b)
/* .e1: pop õ8
b=6
LevaSpaziDa_i()
a==";"#.1
PrendiWord_jki()
jc .e|a==0#.f
b-=c |>?#.6|b=1
..6: Spazi_j(b)
..7: LevaSpaziDa_i()
a==";"!#.7a
..5a: b=32|c=j|c-=[s+20]
b-=c| >?#.6a| b=1
..6a: Spazi_j(b)| ##.1
..7a: a==0#.f
a!=","!#.8|Spazi_j(2)|jc .e
..8: PrendiWord_jki()
jc .e|a==0#.f
B[j-1]==';'!#.9
B[j-1]=0|--j,i|#.5a
..9: #.7
..z:

>b,i,j,k

ret 12

Aug 19 '08 #20

santosh

rio wrote:

<snip>

i think all you miss the use of goto + indentation
is more readable of all your for() while() loops
all together

Yes, fifty years of software engineering has been the result of misled
people, who should've listended to you instead.

Aug 19 '08 #21

Bartc

"rio" <a@b.cwrote in message
news:48**********************@reader1.news.tin.it. ..

>
"Herbert Rosenau" <os****@pc-rosenau.deha scritto nel messaggio
news:wm***************************@JUPITER.PC-ROSENAU.DE...
>On Sun, 17 Aug 2008 22:25:45 UTC, Keith Thompson <ks***@mib.org>
wrote:

if you say that goto is so impractical so it is a miracle
that the below routine run well and i, even if know
something of C believe, i could not write something easier
in C

Are you the guy from c.l.a.x86 with the weird language?

; parametri: i la stringa da leggere
; j la stringa da scrivere
; k la size di j

That should be 'il size' surely?

/* u32 FormatA(u32* ArrOut,u32 ArrSize,u32* ArrIn)
/* 0k,4j,8i,12b,16ra,
/* 20PArrOut,24PArrSize,28PArrIn
FormatA:
<b,i,j,k
j=[s+20]|k=[s+24]|i=[s+28]
j==0#.e |k<=0?#.e|i#.2

.....

B[j-1]=0|--j,i|#.5a

I've always had problems with the unlovely syntax of C, but now I take it
all back...

At least you seem to have eliminated 'goto'.

--
Bartc

Aug 19 '08 #22

santosh

Bartc wrote:

"rio" <a@b.cwrote in message
news:48**********************@reader1.news.tin.it. ..
>>
"Herbert Rosenau" <os****@pc-rosenau.deha scritto nel messaggio
news:wm***************************@JUPITER.PC-ROSENAU.DE...
>>On Sun, 17 Aug 2008 22:25:45 UTC, Keith Thompson <ks***@mib.org>
wrote:

>if you say that goto is so impractical so it is a miracle
that the below routine run well and i, even if know
something of C believe, i could not write something easier
in C

Are you the guy from c.l.a.x86 with the weird language?

>; parametri: i la stringa da leggere
; j la stringa da scrivere
; k la size di j

That should be 'il size' surely?

>/* u32 FormatA(u32* ArrOut,u32 ArrSize,u32* ArrIn)
/* 0k,4j,8i,12b,16ra,
/* 20PArrOut,24PArrSize,28PArrIn
FormatA:
<b,i,j,k
j=[s+20]|k=[s+24]|i=[s+28]
j==0#.e |k<=0?#.e|i#.2
....
> B[j-1]=0|--j,i|#.5a

I've always had problems with the unlovely syntax of C, but now I take
it all back...

You must see his private x86 assembly syntax, which he often used to
post to alt.lang.asm.

At least you seem to have eliminated 'goto'.

I wonder what Dijkstra would've said of his code. :-)

Aug 19 '08 #23

ediebur

On Aug 17, 6:25*pm, Keith Thompson <ks...@mib.orgwrote:

raashid bhatt <raashidbh...@gmail.comwrites:
why are GOTO's not used they just a simple JMP instructions what's bad
about them

There's a tremendous amount of literature about this, going back at
least to Dijstra's 1968 letter "Go To Statement Considered Harmful".

But here's my summary of why goto statements should *usually* be
avoided.

Most control flow constructs used in programs (if, if/else, for,
while, do/while, etc.) reflect concepts in the problem domain:

* * Do this, but only under these circumstances.
* * Do this under these circumstances; otherwise do that.
* * Do this that many times.
* * Repeatedly do this as long as this condition still holds.

The goto statement, on the other hand, reflects a concept in the
source code of your program:

* * Jump to the statement in this function with the label "FOO".

If you make the structure of your code reflect the structure of the
problem the code is trying to solve, it's easier to maintain.

Having said that, there are cases where a goto statement can be
justified -- and most of those times, it's a replacement for a control
flow construct that's missing from the language.

For example, C provides no way to break out of nested loops. *A goto
statement can act as a replacement for a multi-level break.
Similarly, C doesn't provide exception handling, a way to abort
execution at a certain point and recover at a higher point; again, a
goto statement can emulate this (but only within a single function).
On the other hand, re-structuring the code is sometimes a better way
to do this. *(It's been argued that multi-level breaks, and perhaps
even single-level breaks, are a bad idea anyway, and that loops should
terminate only at the bottom.)

Finally, if you're coding an explicit finite state machine, a goto
statement *can* reflect a concept in the problem domain, namely
transitioning from one state to another, where the current state is
represented by where you are in the code. *(On the other hand, another
way to implement this is to use an enum variable for the state and
write a switch statement inside a loop.)

In practice, excessive use of goto statements can easily lead to
so-called "spaghetti code", in which the behavior of any piece of the
code isn't obvious until you understand *all* the code. *Code without
gotos is often easier to maintain.

If you must use goto statements, it's best to have them branch only
forward in the code; this minimizes spagettification.

Like any debate about style, there are opposing viewpoints.

--
Keith Thompson (The_Other_Keith) ks...@mib.org *<http://www.ghoti.net/~kst>
Nokia
"We must do something. *This is something. *Therefore, we must do this."
* * -- Antony Jay and Jonathan Lynn, "Yes Minister"

I haven't actually programmed in a while but I have about 20 years
experience, last 10 years in C. I learned in Pascal a long time ago.
When I first started C, I think it was in a night course at BU, I
decided to try to use a goto ( I think I was writing a simple editor).
I got myself in trouble quite quickly and spent most of my time
debugging that goto code and never did get it correct. Since then I
never used one although I have seen code ( some kernel code I think)
where a goto was used in a readable effective manner. For myself, I
never needed it and was afraid to try again

Aug 19 '08 #24

rio

"Bartc" <bc@freeuk.comha scritto nel messaggio
news:e9*******************@text.news.virginmedia.c om...

>/* u32 FormatA(u32* ArrOut,u32 ArrSize,u32* ArrIn)
/* 0k,4j,8i,12b,16ra,
/* 20PArrOut,24PArrSize,28PArrIn
FormatA:
<b,i,j,k
j=[s+20]|k=[s+24]|i=[s+28]
j==0#.e |k<=0?#.e|i#.2
....
> B[j-1]=0|--j,i|#.5a

I've always had problems with the unlovely syntax of C, but now I take it
all back...

At least you seem to have eliminated 'goto'.

wrong one; "#" or "##" is at last one goto
i had counted 60 in that routine

--
Bartc

Aug 19 '08 #25

"rio" <a@b.cwrites:

"santosh" <sa*********@gmail.comha scritto nel messaggio

<snip>

>Just compare these two code fragments that do the same thing:

1.

1 for (i = 0; i < 10; i++) {
2 for (j = 0; j < 10; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

yes "Just compare"

1 i=0;
2 .0: j=0; /* 0,1,..9 */
3 .1: putc('*' , stdout); if(++j<10) goto .1;
4 putc('\n', stdout); if(++i<10) goto .0;

i think you have found the wrong example
the goto one doesn't seem so dark.
Possibly someone will be luck next time
for find one example where goto is inferior

The example is not a very good one. Why use such complex code to
perform a fixed task? If you make it more realistic by replaying the
upper bounds in both cases with n and m you will see the inferiority
of the goto version.

--
Ben.

Aug 19 '08 #26

rio

"Ben Bacarisse" <be********@bsb.me.ukha scritto nel messaggio
news:87************@bsb.me.uk...

"rio" <a@b.cwrites:

>"santosh" <sa*********@gmail.comha scritto nel messaggio
<snip>

>>Just compare these two code fragments that do the same thing:

1.

1 for (i = 0; i < 10; i++) {
2 for (j = 0; j < 10; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

yes "Just compare"

1 i=0;
2 .0: j=0; /* 0,1,..9 */
3 .1: putc('*' , stdout); if(++j<10) goto .1;
4 putc('\n', stdout); if(++i<10) goto .0;

i think you have found the wrong example
the goto one doesn't seem so dark.
Possibly someone will be luck next time
for find one example where goto is inferior

The example is not a very good one. Why use such complex code to
perform a fixed task? If you make it more realistic by replaying the
upper bounds in both cases with n and m you will see the inferiority
of the goto version.

where is the suppose inferiority of goto?
it can traslate all you loop and doing new loop something
no one have ever seen :)

>1 for (i = 0; i < n; i++) {
2 for (j = 0; j < m; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

i=0; goto .4;
..0: j=0; goto .2;
..1: putc('*', stdout); ++j;
..2: if(j<m) goto .1;
..3: putc('\n', stdout); ++i;
..4: if(i<n) goto .0;

--
Ben.

Aug 19 '08 #27

santosh

rio wrote:

>
"Ben Bacarisse" <be********@bsb.me.ukha scritto nel messaggio
news:87************@bsb.me.uk...
>"rio" <a@b.cwrites:

>>"santosh" <sa*********@gmail.comha scritto nel messaggio
<snip>
>>>Just compare these two code fragments that do the same thing:

1.

1 for (i = 0; i < 10; i++) {
2 for (j = 0; j < 10; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

yes "Just compare"

1 i=0;
2 .0: j=0; /* 0,1,..9 */
3 .1: putc('*' , stdout); if(++j<10) goto .1;
4 putc('\n', stdout); if(++i<10) goto .0;

i think you have found the wrong example
the goto one doesn't seem so dark.
Possibly someone will be luck next time
for find one example where goto is inferior

The example is not a very good one. Why use such complex code to
perform a fixed task? If you make it more realistic by replaying the
upper bounds in both cases with n and m you will see the inferiority
of the goto version.

where is the suppose inferiority of goto?
it can traslate all you loop and doing new loop something
no one have ever seen :)

Nice hobby but you won't get far in professional level with this sort of
attitude.

Aug 19 '08 #28

"rio" <a@b.cwrites:
[...]

where is the suppose inferiority of goto?
it can traslate all you loop and doing new loop something
no one have ever seen :)

>>1 for (i = 0; i < n; i++) {
2 for (j = 0; j < m; j++) {
3 putc('*', stdout);
4 }
5 putc('\n', stdout);
6 }

i=0; goto .4;
.0: j=0; goto .2;
.1: putc('*', stdout); ++j;
.2: if(j<m) goto .1;
.3: putc('\n', stdout); ++i;
.4: if(i<n) goto .0;

I don't know what language this is supposed to be, but it certainly
isn't C.

This "rio" is a long-time troll who has posted under a variety of
names, including "RoSsIaCrIiLoIA" and "av". I suggest ignoring him.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Aug 19 '08 #29

rio

"santosh" <sa*********@gmail.comha scritto nel messaggio
news:g8**********@registered.motzarella.org...

>where is the suppose inferiority of goto?
it can traslate all you loop and doing new loop something
no one have ever seen :)

Nice hobby but you won't get far in professional level with this sort of
attitude.

if to be professional means turn the think off and follow some one
whitout any criticize than it is better hobby.
if you can write a loop that show to be more difficul with goto
ok otherwise it is better to be in silence.

Aug 20 '08 #30

Richard Bos

"Bartc" <bc@freeuk.comwrote:

That's a far-fetched example. Used properly, to augment existing control
structures, Goto is not such a big deal as people seem to think. Used by
code-generaters (generating C-code) it's a non-issue because the code will
never be seen or maintained.

And it's a natural control structure that many people will be familiar with,
eg. on lists of instructions and any number of forms ("If you answered No,
please proceed to question 8...").

Hum. People may be familiar with choose-your-own-adventure forms, but
I've never spoken to anyone who likes them, except civil servants from
the tax office.

Richard

Aug 20 '08 #31

On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:

That's a far-fetched example. Used properly, to augment existing control
structures, Goto is not such a big deal as people seem to think. Used by
code-generaters (generating C-code) it's a non-issue because the code will
never be seen or maintained.

No, got breaks the flow. It requires a label somewhere. The existence
of a label is a sign to seharch for multiple gotos somewhere else. and
breaks the flow only because it exists.

And it's a natural control structure that many people will be familiar with,
eg. on lists of instructions and any number of forms ("If you answered No,
please proceed to question 8...").

No, it hinders to see the real flow. It is a real break in
maintenance. However wwhen you has to maintain a program that was
written some years ago by somebody who has left that job it's always
hard and timecostly to get tthe idea he had how to write that goto,
how the label was set .... it makes it really hard to maintain this
mixup of labels and gotos.

Of course it can be abused, but so can lots of things.

goto IS abusitive always.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

Aug 20 '08 #32

On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:

That's a far-fetched example. Used properly, to augment existing control
structures, Goto is not such a big deal as people seem to think. Used by
code-generaters (generating C-code) it's a non-issue because the code will
never be seen or maintained.

And it's a natural control structure that many people will be familiar with,
eg. on lists of instructions and any number of forms ("If you answered No,
please proceed to question 8...").

Of course it can be abused, but so can lots of things.

Why get I so easy confused? Whenever I see the letters Twink I read
them as Twit. Any idea why it is so?

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

Aug 20 '08 #33

santosh

Herbert Rosenau wrote:

On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:

>That's a far-fetched example. Used properly, to augment existing
control structures, Goto is not such a big deal as people seem to
think. Used by code-generaters (generating C-code) it's a non-issue
because the code will never be seen or maintained.

And it's a natural control structure that many people will be
familiar with, eg. on lists of instructions and any number of forms
("If you answered No, please proceed to question 8...").

Of course it can be abused, but so can lots of things.

Why get I so easy confused? Whenever I see the letters Twink I read
them as Twit. Any idea why it is so?

No idea, but in any case, why are you asking *Bartc* this question,
instead of Twink?

Aug 20 '08 #34

Richard Tobin

In article <wm***************************@JUPITER.PC-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.dewrote:

>No, got breaks the flow. It requires a label somewhere.

So it breaks the flow. So what? Are you suggesting that correctly
written programs have unbroken flow?

>The existence
of a label is a sign to seharch for multiple gotos somewhere else. and
breaks the flow only because it exists.

Most functions I've written that use goto have only one label.

The fact is that C doesn't provide all the control flow constructs
commonly needed, so it's necessary to simulate some of them. You
don't have to use goto for this, but it's sometimes the clearest way.
The tricks commonly used to avoid goto - duplicated code, variables
with names like "found" and "done" - are often much worse.

>No, it hinders to see the real flow. It is a real break in
maintenance. However wwhen you has to maintain a program that was
written some years ago by somebody who has left that job it's always
hard and timecostly to get tthe idea he had how to write that goto,
how the label was set .... it makes it really hard to maintain this
mixup of labels and gotos.

Now you exaggerate. Who said anything about a "mixup of labels
and gotos"?

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Aug 20 '08 #35

Stan Milam

Ian Collins wrote:

santosh wrote:
>Malcolm McLean wrote:

>>"raashid bhatt" <ra**********@gmail.comwrote in message news:
why are GOTO's not used they just a simple JMP instructions what's
bad about them

Indeed. C has a perfectly functional goto statement, which will
compile to a basic assembler jump.
I note that you have failed to actually answer the OP's question.

To the OP:

It's not true to say that the goto is "not used". It's use is often
discouraged, but it's nevertheless used in some situations. Unlike
gets, goto *can* be used wisely, though in my experience, you need
quite some practise in programming before you can acquire this ability.

And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!

For years I refused to write a goto in my code. Then I started using a
variant of ADA that could raise either implicitly, or explicitly. The
exception would then be caught by an exception section of code. I came
to love this feature and when I started writing C again I wanted it
back. I realized all the exception handling thing was doing was very
controlled goto. So, I implemented almost exactly the same thing using
preprocessor macros and I use them almost daily. The code is so much
cleaner now, and since the semantics of the macros are exceptions the
programmer *never thinks* it is a goto.

Quote (perhaps paraphrased): "If you want to go somewhere, a goto is the
fastest way to get there." Ken Thompson.

--
Regards,
Stan Milam.
--
"The distractions of constant e-mails, text and phone messages
are a greater threat to IQ and concentration than taking cannabis."
Glen Wilson, Industrial Psychologist

Aug 21 '08 #36

Ian Collins

Stan Milam wrote:

Ian Collins wrote:
>>
And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!

For years I refused to write a goto in my code. Then I started using a
variant of ADA that could raise either implicitly, or explicitly. The
exception would then be caught by an exception section of code. I came
to love this feature and when I started writing C again I wanted it
back. I realized all the exception handling thing was doing was very
controlled goto. So, I implemented almost exactly the same thing using
preprocessor macros and I use them almost daily. The code is so much
cleaner now, and since the semantics of the macros are exceptions the
programmer *never thinks* it is a goto.

Assuming the programmer knows to write exception safe code. Exception
implementations in C are invariably half-arsed.
--
Ian Collins.

Aug 21 '08 #37

On Wed, 20 Aug 2008 21:00:55 UTC, ri*****@cogsci.ed.ac.uk (Richard
Tobin) wrote:

In article <wm***************************@JUPITER.PC-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.dewrote:

No, got breaks the flow. It requires a label somewhere.

So it breaks the flow. So what? Are you suggesting that correctly
written programs have unbroken flow?

The existence
of a label is a sign to seharch for multiple gotos somewhere else. and
breaks the flow only because it exists.

Most functions I've written that use goto have only one label.

wheras a label has always an unknown number of source. So goto makes a
program unmaintable always!

It doesn't matter if a function has currently ony one ore one million
gotos. Having a lable makes the whole program unmaintable because at
the point the label exist there is absolutely nothing that says that
this label is reached fom only one point and where that point is and
what state the flow has. There is in no way a need for goto. There is
noways a need to set a lablel as destination of a goto. When you means
you needs a goto then your design is highly buggy and needs to be
replaced by another one.

The fact is that C doesn't provide all the control flow constructs
commonly needed, so it's necessary to simulate some of them. You
don't have to use goto for this, but it's sometimes the clearest way.
The tricks commonly used to avoid goto - duplicated code, variables
with names like "found" and "done" - are often much worse.

That is completely false. C owns all you need to have perfect control.
You have if - else, for, do, while, break, continue, and at least
return.

There is absolutely no need to duplicate code - except sometimes for
speed up.

No, it hinders to see the real flow. It is a real break in
maintenance. However wwhen you has to maintain a program that was
written some years ago by somebody who has left that job it's always
hard and timecostly to get tthe idea he had how to write that goto,
how the label was set .... it makes it really hard to maintain this
mixup of labels and gotos.

Now you exaggerate. Who said anything about a "mixup of labels
and gotos"?

a goto without a label is an error - always. So using goto without
label is senseless - so you ends up with a mixup of got and label -
always you uses goto.

There is in no circumstance a need for goto, except do produce
unmaintable code.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

Aug 21 '08 #38

Nick Keighley

On 21 Aug, 11:03, "Herbert Rosenau" <os2...@pc-rosenau.dewrote:

On Wed, 20 Aug 2008 21:00:55 UTC, rich...@cogsci.ed.ac.uk (Richard
Tobin) wrote:
In article <wmzsGguTDN6N-pn2-d9LdBMYXn...@JUPITER.PC-ROSENAU.DE>,
Herbert Rosenau <os2...@pc-rosenau.dewrote:

>No, got breaks the flow. It requires a label somewhere.

So it breaks the flow. *So what? *Are you suggesting that correctly
written programs have unbroken flow?

>The existence
>of a label is a sign to *seharch for multiple gotos somewhere else. and
>breaks the flow only because it exists.

Most functions I've written that use goto have only one label.

wheras a label has always an unknown number of source. So goto makes a
program unmaintable always!

since a goto in C is always confined to the same function
a small function may be perfectly maintainable even
with a goto.

It doesn't matter if a function has currently ony one ore one million
gotos. Having a lable makes the whole program unmaintable because at
the point the label exist there is absolutely nothing that says that
this label is reached fom only one point and where that point is and
what state the flow has. There is in no way a need for goto. There is
noways a need to set a lablel as destination of a goto. When you means
you needs a goto then your design is highly buggy and needs to be
replaced by another one.

The fact is that C doesn't provide all the control flow constructs
commonly needed, so it's necessary to simulate some of them. *You
don't have to use goto for this, but it's sometimes the clearest way.
The tricks commonly used to avoid goto - duplicated code, variables
with names like "found" and "done" - are often much worse.

That is completely false. C owns all you need to have perfect control.
You have if - else, for, do, while, break, continue, and at least
return.

there's no escape from a deeply nested loop.

There is absolutely no need to duplicate code - except sometimes for
speed up.

>No, it hinders to see the real flow. It is a real break in
>maintenance. However wwhen you has to maintain a program that was
>written some years ago by somebody who has left that job it's always
>hard and timecostly to get tthe idea he had how to write that goto,
>how the label was set .... it makes it really hard to maintain this
>mixup of labels and gotos.

Now you exaggerate. *Who said anything about a "mixup of labels
and gotos"?

a goto without a label is an error - always. So using goto without
label is senseless - so you ends up with a mixup of got and label -
always you uses goto.

There is in no circumstance a need for goto, except do produce
unmaintable code.

I'm being a bit of a devil's advocate. I havn't used a goto in
<mumbleyears. And a fellow (Italian) programmer exclaimed:
"Nick, you are a software beast!"
--
Nick Keighley

My name's Richard, and I'm an ex-goto addict.
...
It's not worth it. It really isn't.
goto: Just Say No.

Aug 21 '08 #39

Ian Collins wrote:

Stan Milam wrote:
>Ian Collins wrote:
>>And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!

For years I refused to write a goto in my code. Then I started using a
variant of ADA that could raise either implicitly, or explicitly. The
exception would then be caught by an exception section of code. I came
to love this feature and when I started writing C again I wanted it
back. I realized all the exception handling thing was doing was very
controlled goto. So, I implemented almost exactly the same thing using
preprocessor macros and I use them almost daily. The code is so much
cleaner now, and since the semantics of the macros are exceptions the
programmer *never thinks* it is a goto.

Assuming the programmer knows to write exception safe code. Exception
implementations in C are invariably half-arsed.

Mmmmm... it's not that bad - setjmp/longjmp work about as
well as C++ try/catch pairs. I've noticed that in dynamic
languages (I tend towards Tcl), "catch" becomes just another
operator, useful as an element of logic flow.... try this? No?
Try that, then....

The advantage in C++ is that the class itself contains enough
context to make catch/try pairs easier to write cleanly.

But setjmp/longjmp, coupled with interrupts can actually
improve (IMO) some otherwise difficult-looking things. It,
of course, destroys locality utterly, but....

--
Les Cargill

Aug 21 '08 #40

Herbert Rosenau wrote:

On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:

<snip>

goto IS abusitive always.

And all universal statements are false :)

--
Les Cargill

Aug 21 '08 #41

Joe Wright

Les Cargill wrote:

Herbert Rosenau wrote:
>On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:
<snip>
>goto IS abusitive always.

And all universal statements are false :)

It was Bertrand Russell I think..
"All generalities are false, including this one."

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Aug 21 '08 #42

Herbert Rosenau wrote:
<snip>

>
There is in no circumstance a need for goto, except do produce
unmaintable code.

The goto is Bad because grad students who grade labs can grep
for it. So it is an easy foul to call.

I find that people who have done large projects in assembler
and still want to program for a living are easier to get along with.
They know goto intimately.

What "goto is Bad" really means is that "We don't want people to
hack in the running system *too* much. Just enough." How much is
too much is a normative decision based on local mores, which
is really more about how money is spent than about anything else.

I once saw a trouble ticket for which the action was to add a comment
"// this is really, really bad" and the ugly was left in because
the system passed test. After a while, like ugly buildings
and (one word meaning "lady of the evening"), they
get respectable after a while.

--
Les Cargill

Aug 21 '08 #43

Les Cargill <lc******@cfl.rr.comwrites:

Herbert Rosenau wrote:
<snip>
> There is in no circumstance a need for goto, except do produce
unmaintable code.

The goto is Bad because grad students who grade labs can grep
for it. So it is an easy foul to call.

That does not make sense to me. Lots of bits of C can be grepped
for -- are they all bad? The "badness" (if it is there) must come
first and be for some other reason than the ease of finding it.

--
Ben.

Aug 21 '08 #44

Andrew Poelstra

On 2008-08-21, Ben Bacarisse <be********@bsb.me.ukwrote:

Les Cargill <lc******@cfl.rr.comwrites:

>Herbert Rosenau wrote:
<snip>
>> There is in no circumstance a need for goto, except do produce
unmaintable code.

The goto is Bad because grad students who grade labs can grep
for it. So it is an easy foul to call.

That does not make sense to me. Lots of bits of C can be grepped
for -- are they all bad? The "badness" (if it is there) must come
first and be for some other reason than the ease of finding it.

Goto's are dogmatically Bad. Your education system must have far
more integrity than mine if they don't grep for Bad keywords as
a marking strategy.
--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net

Aug 21 '08 #45

Les Cargill <lc******@cfl.rr.comwrites:

Ian Collins wrote:
>Stan Milam wrote:
>>Ian Collins wrote:
And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!

For years I refused to write a goto in my code. Then I started using a
variant of ADA that could raise either implicitly, or explicitly. The
exception would then be caught by an exception section of code. I came
to love this feature and when I started writing C again I wanted it
back. I realized all the exception handling thing was doing was very
controlled goto. So, I implemented almost exactly the same thing using
preprocessor macros and I use them almost daily. The code is so much
cleaner now, and since the semantics of the macros are exceptions the
programmer *never thinks* it is a goto.

Assuming the programmer knows to write exception safe code. Exception
implementations in C are invariably half-arsed.

Mmmmm... it's not that bad - setjmp/longjmp work about as
well as C++ try/catch pairs. I've noticed that in dynamic
languages (I tend towards Tcl), "catch" becomes just another
operator, useful as an element of logic flow.... try this? No?
Try that, then....

I think setjmp/longjmp as a try/catch mechanism fits well inside the
boundary of "half-arsed". There is no comparison with a system where
resources can be reclaimed as the stack is unwound.

--
Ben.

Aug 21 '08 #46

Andrew Poelstra <ap*******@supernova.homewrites:

On 2008-08-21, Ben Bacarisse <be********@bsb.me.ukwrote:
>Les Cargill <lc******@cfl.rr.comwrites:

>>Herbert Rosenau wrote:
<snip>
There is in no circumstance a need for goto, except do produce
unmaintable code.
The goto is Bad because grad students who grade labs can grep
for it. So it is an easy foul to call.

That does not make sense to me. Lots of bits of C can be grepped
for -- are they all bad? The "badness" (if it is there) must come
first and be for some other reason than the ease of finding it.

Goto's are dogmatically Bad. Your education system must have far
more integrity than mine if they don't grep for Bad keywords as
a marking strategy.

Since I was part of it, I can categorically confirm that I (at least)
have never applied such crude measure to a student's program. I
discouraged goto (in fact, I doubt it was ever brought up though the
textbooks would have it) but if it was well used (e.g. jump to some
tidy up code from a nested loop) I would not mark it down, though I'd
discuss alternatives.

--
Ben.

Aug 21 '08 #47

Ben Bacarisse wrote:

Les Cargill <lc******@cfl.rr.comwrites:

>Ian Collins wrote:
>>Stan Milam wrote:
Ian Collins wrote:
And by the time you have reached that point, you learn the alternatives
and never have to resort to goto!
>
For years I refused to write a goto in my code. Then I started using a
variant of ADA that could raise either implicitly, or explicitly. The
exception would then be caught by an exception section of code. I came
to love this feature and when I started writing C again I wanted it
back. I realized all the exception handling thing was doing was very
controlled goto. So, I implemented almost exactly the same thing using
preprocessor macros and I use them almost daily. The code is so much
cleaner now, and since the semantics of the macros are exceptions the
programmer *never thinks* it is a goto.

Assuming the programmer knows to write exception safe code. Exception
implementations in C are invariably half-arsed.

Mmmmm... it's not that bad - setjmp/longjmp work about as
well as C++ try/catch pairs. I've noticed that in dynamic
languages (I tend towards Tcl), "catch" becomes just another
operator, useful as an element of logic flow.... try this? No?
Try that, then....

I think setjmp/longjmp as a try/catch mechanism fits well inside the
boundary of "half-arsed". There is no comparison with a system where
resources can be reclaimed as the stack is unwound.

"Doctor, doctor, it hurts when I do that...."

I believe you just made the comparison.... I'm increasingly
of the mind that if you need such a thing, dynamic
languages are the better choice.

--
Les Cargill

Aug 21 '08 #48

Ben Bacarisse wrote:

Les Cargill <lc******@cfl.rr.comwrites:

>Herbert Rosenau wrote:
<snip>
>> There is in no circumstance a need for goto, except do produce
unmaintable code.

The goto is Bad because grad students who grade labs can grep
for it. So it is an easy foul to call.

That does not make sense to me. Lots of bits of C can be grepped
for -- are they all bad? The "badness" (if it is there) must come
first and be for some other reason than the ease of finding it.

"...so it is an easy foul to call."

*In essence*, Dijkstra's paper called for code to be structured
as-a-tree, not as a linear, unrolled morph of a tree. An "if"
is a binary operator over the domain of blocks of code, which is
considerably more algebraic than a goto. Therefore, so is a while,
a for...

That's the "normative" part of things. Now that we
have a norm, an easy detection for violation of the norm
makes it much more likely to be enforced....

--
Les Cargill

Aug 21 '08 #49