469,353 Members | 2,053 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,353 developers. It's quick & easy.

why are GOTO's not used ...

why are GOTO's not used they just a simple JMP instructions what's bad
about them
Aug 17 '08
59 4562
santosh wrote:
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?
Maybe because Twink didn't write a single article in this thread?

Bye, Jojo
Aug 21 '08 #51
Keith Thompson <ks***@mib.orgwrites:
Joe Wright <jo********@comcast.netwrites:
>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."

<OT>
"generalizations", not "generalities". A quick Google search turns up
a couple of attributions to Mark Twain, but I remember it being
attributed to Voltaire, or maybe it was Descartes.
</OT>
If I may <OTjust a little more. The attribution or mis-attribution
to Russell is natural since it is his name that has become attached
this whole class (mathematical pun intended) of paradoxes. My
favourite example in programming (I can't get it back to C) was a
SNOBOL pattern that matched only those patterns that did not match
themselves. The program, of course, matched this pattern to itself.

--
Ben.
Aug 21 '08 #52
"Herbert Rosenau" <os****@pc-rosenau.dewrites:
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.
[...]

As many people have said, "All generalizations are false, including
this one".

I don't remember the last time I used a goto (other than in some
scripting "language" that really didn't have anything better); I'm not
sure that I've *ever* written a goto in C.

Having said that, a goto statement and its target label are always
within the same function. If that function is short enough, a moment
of reading is enough to ensure that there's only one goto statement
and only one label.

For example:

int foo(blah)
{
for (blah; blah; blah) {
for (blah; blah; blah) {
if (need_to_bail_out_now) {
goto ERROR;
}
}
}
return OK;

ERROR:
return ERROR_FLAG;
}

Given sufficiently clear identifiers, the control flow is fairly
obvious and maintenance shouldn't be too much of a problem. Here the
goto statement substitutes for C's lack of a multi-level break.

Now a lot of programmers would restructure this code to avoid the
goto. I would very likely do so myself. But that's largely a matter
of taste. The (pseudo-)code as written, even with a goto statement,
isn't "highly buggy".

Yes, every program that uses gotos can be rewritten to avoid them;
that's a theorem that's been known for decades. That *doesn't* imply
that the gotoless version is unambiguously better.

--
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 21 '08 #53
On Aug 20, 3:09*pm, "Herbert Rosenau" <os2...@pc-rosenau.dewrote:
On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <b...@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

Visithttp://www.ecomstation.dethe home of german eComStation
eComStation 1.2R Deutsch ist da!
I once had to fix a program by a coder who was new to C but evidently
thought he was the bee's knees.Had a few gotos which were easy but he
insisted on complicated return expression (return <expression>).
Debugging that just plain s*cked.
Aug 21 '08 #54
On 21 Aug 2008 at 16:19, Joachim Schmitz wrote:
santosh wrote:
>Herbert Rosenau wrote:
>>On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:
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?

Maybe because Twink didn't write a single article in this thread?
Huh? I'm confused...

Aug 21 '08 #55
Antoninus Twink wrote:
On 21 Aug 2008 at 16:19, Joachim Schmitz wrote:
>santosh wrote:
>>Herbert Rosenau wrote:
On Mon, 18 Aug 2008 22:20:32 UTC, "Bartc" <bc@freeuk.comwrote:
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?

Maybe because Twink didn't write a single article in this thread?

Huh? I'm confused...
I correct resp. extend my statement: ... before his (Herbert's) post.

Don't worry, this isn't supposed to make any sense, and was carefully
designed to confuse.
That's what GOTOs are all about after all 8-)

Bye, Jojo
Aug 21 '08 #56
Joachim Schmitz wrote:
santosh wrote:
Herbert Rosenau wrote:
....
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?

Maybe because Twink didn't write a single article in this thread?
That just moves the question farther back, without truly answering it.
Why was a comment about the letters "Twink" posted to a thread in
which those letters never occurred?
Aug 21 '08 #57
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Having said that, a goto statement and its target label are always
within the same function. If that function is short enough, a moment
of reading is enough to ensure that there's only one goto statement
and only one label.
What's more, unlike other control structures, the user chooses a
name for the target.

This:
goto ERROR;
makes the intention - that the transfer occurs when there's an error -
clear in a way that C's other within-function control structures
don't.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Aug 21 '08 #58
On Thu, 21 Aug 2008 16:40:30 UTC, Keith Thompson <ks***@mib.org>
wrote:

Having said that, a goto statement and its target label are always
within the same function. If that function is short enough, a moment
of reading is enough to ensure that there's only one goto statement
and only one label.

For example:

int foo(blah)
{
for (blah; blah; blah) {
for (blah; blah; blah) {
if (need_to_bail_out_now) {
goto ERROR;
Boo! ssimply return ERROR_FAILED; would not break the flow, disturb
sequence and hinder to get something more bad. When that nested
blocks were a little bit more complex I would break down the whole
function in hiding implemenation details in a lower level function(s).
This would win a better overview in what is going on, leaving goto out
the door.
}
}
}
return OK;

ERROR:
return ERROR_FLAG;
}

Given sufficiently clear identifiers, the control flow is fairly
obvious and maintenance shouldn't be too much of a problem. Here the
goto statement substitutes for C's lack of a multi-level break.
When you had had the job to maintain code written by others who are
never available to ask for this or that then you would hate each and
any got you hast to handle.
Now a lot of programmers would restructure this code to avoid the
goto. I would very likely do so myself. But that's largely a matter
of taste. The (pseudo-)code as written, even with a goto statement,
isn't "highly buggy".
It is because you'll gets highly overloded when you have to maintain
this crap later on.
Yes, every program that uses gotos can be rewritten to avoid them;
that's a theorem that's been known for decades. That *doesn't* imply
that the gotoless version is unambiguously better.
It is better to avoid goto always. You may write goto when you hates
anybody else and tries to make theyr work impossibe, you tries to
bring the company the code release into ruin or you are a coder (real
programmers would never use goto) without ability to think.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Aug 22 '08 #59
rio

"Herbert Rosenau" <os****@pc-rosenau.deha scritto nel messaggio
news:wm***************************@JUPITER.PC-ROSENAU.DE...
On Thu, 21 Aug 2008 16:40:30 UTC, Keith Thompson <ks***@mib.org>
wrote:

>Having said that, a goto statement and its target label are always
within the same function. If that function is short enough, a moment
of reading is enough to ensure that there's only one goto statement
and only one label.

For example:

int foo(blah)
{
for (blah; blah; blah) {
for (blah; blah; blah) {
if (need_to_bail_out_now) {
goto ERROR;

Boo! ssimply return ERROR_FAILED; would not break the flow,
Is it possible that you have a meaning too restrict for the word flow?
it is like i see flow has many dimensions
and other say "no it has one dimension only"
disturb
sequence and hinder to get something more bad.
the same routine that has the same difficulty
the goto one + indentation here seems the more readable

if the limit of complexity (for to be understandable by me) for a c routine
that use while() if() etc is 10 in C
it is 100 in assembly that use goto

if i have to say the true this is only for my home made
language that use some insane number of gotos (at last for you)
but seems more robust and sure of the one i wrote in c
When that nested
blocks were a little bit more complex I would break down the whole
function in hiding implemenation details in a lower level function(s).
This would win a better overview in what is going on, leaving goto out
the door.
> }
}
}
return OK;

ERROR:
return ERROR_FLAG;
}

Given sufficiently clear identifiers, the control flow is fairly
obvious and maintenance shouldn't be too much of a problem. Here the
goto statement substitutes for C's lack of a multi-level break.

When you had had the job to maintain code written by others who are
never available to ask for this or that then you would hate each and
any got you hast to handle.
if something is more readable, if you have to ask something to someone
for a goto, you have to ask 100 times more for a while() or other
>Now a lot of programmers would restructure this code to avoid the
goto. I would very likely do so myself. But that's largely a matter
of taste. The (pseudo-)code as written, even with a goto statement,
isn't "highly buggy".

It is because you'll gets highly overloded when you have to maintain
this crap later on.
>Yes, every program that uses gotos can be rewritten to avoid them;
that's a theorem that's been known for decades. That *doesn't* imply
that the gotoless version is unambiguously better.

It is better to avoid goto always. You may write goto when you hates
anybody else and tries to make theyr work impossibe, you tries to
bring the company the code release into ruin or you are a coder (real
programmers would never use goto) without ability to think.
at last cpu and oses seems understand what i say.
programming is not live in a heaven,
it is more like live in the hell but building the heaven.
--
Tschau/Bye
Herbert

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


Aug 22 '08 #60

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

36 posts views Thread by Michael | last post: by
51 posts views Thread by WindAndWaves | last post: by
37 posts views Thread by Tim Marshall | last post: by
77 posts views Thread by M.B | last post: by
34 posts views Thread by electrician | last post: by
3 posts views Thread by electrician | last post: by
7 posts views Thread by raashid bhatt | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.