on goto
io_x
comp.lang.c, comp.lang.c++, comp.programming]
the people that speak not good about "goto"
are uttled wrong; their code bug full etc
more distant is your code from goto
more your code is bug full and incompresible
the "goto" is the key word for programming;
all the remain, other than goto or jmp or jc or jz,
and the easy cpu layout
is the wrong way for programming
i advise all you
Good Morning
Ali Karaali
reason to ban goto.
Ali
Alexei A. Frounze
Everything may be used, misused and abused, goto included. There are
good and bad usage patterns and goto is not an exception here. I can
list a number of other things that may be just as bad as a poorly used
goto (or as good as a good goto). See?
Alex
Mensanator
Yeah, there's nothing more fun than converting BASIC to Pascal.
Only to discover that goto was used to return from a sub-routine
without clearing the stack.
spinoza1111
> I use goto to break nested for loops and I can't see a
> reason to ban goto.
Why not use break instead? Does the same thing, spares you from having
to define a label.
There are two senses in which a program can be structured.
The first is syntactical, and to be syntactically structured, the
source code of the program must be restricted to structured syntax, of
which neither goto nor break is a strict example. You'd have to
simulate the break logic:
broken = false;
for(!broken && condition)
{
.
.
.
if (exceptional condition) broken = true;
else
{
.
.
.
}
}
The second is semantic. To be structured in this way, the program must
be decomposable without change into blocks, each at most one entry and
at most one exit, and each of which is one of the Bohm-Jacopini
constructs process, if..then..else, or do while.
If the program is syntactically structured, it must be semantically
structured. But the reverse is not true; an assembler program using go
to can be semantically structured but it is not syntactically
structured, like this inefficient and contrived example
LOAD 0
STOR i
LBL1:
LOAD i
COMP limit
IFGE LBL19
.
.
.
IFEQ LBL12
LOAD j
STOR v
GOTO LBL129
LBL12:
LOAD k
STOR v2
LBL129:
.
.
.
LOAD i
ADD 1
STOR i
GOTO LBL1
LBL19:
Then, certain extensions are permitted including most famously case
without fallthrough, one trip do "until", and break, implemented
semantically with a go to to a label one past the end of the loop or
syntactically with break.
A breaking loop is a new structure relative to the three Bohm-Jacopini
structures, switch case and one trip do. And it "weakens" the
postconditions that must obtain on exit. Most famously, the index of a
breaking loop may not be one past the end of what was being processed.
Pascal J. Bourguignon
Indeed. For example, the Duff device is worse than most gotos I've
ever seen.
--
__Pascal Bourguignon__
Leigh Johnston
"spinoza1111" <spino...@yahoo.com> wrote in message
news:051fa27d-5cf8-4f7e...@g34g2000pro.googlegroups.com...
> On Apr 24, 6:06 pm, Ali Karaali <ali...@gmail.com> wrote:
>> I use goto to break nested for loops and I can't see a
>> reason to ban goto.
>
> 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.
/Leigh
Rui Maciel
I see there is a small misconception in this issue. The only nasty thing that is usually
said about goto is that it's use may end up generating code which isn't easy to read, to
interpret and to follow.
Adding to that, high level languages implement multiple flavors of conditionals and loops,
which end up performing the exact same tasks goto is used for but in a way which is
"cleaner", easier to read, to interpret and to follow.
Yet, loop/conditionals aren't and be all, end all solution. Some tasks, such as state
machines, can still be better implemented with the plain old goto, sometimes in a "cleaner"
way than with any mix of loop/conditionals which are available in any high level language.
So, in essence, goto isn't the problem nor is it a problem. It's just a way of performing
certain tasks. Sometimes it isn't the best tool and sometimes it isn't the worst tool.
Nonetheless, that doesn't make it bad.
On the other hand, popular misconceptions which are often cited but aren't based on any
objective reasoning can constitute a problem, and this appears to be one of those cases.
Rui Maciel
Daniel T.
This is probably a troll, but it is a good opportunity to suggest to
everyone who is tempted to argue about this issue to start from
Dijkstra's paper rather than simply asserting that "goto is good"
without understanding the issues involved.
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
Harmful.html
bartc
"Daniel T." <dani...@earthlink.net> wrote in message
news:daniel_t-623394...@70-3-168-216.pools.spcsdns.net...
> "io_x" <a...@b.c.invalid> wrote:
>> the "goto" is the key word for programming; all the remain, other than
>> goto or jmp or jc or jz, and the easy cpu layout is the wrong way for
>> programming
>>
>> i advise all you
>> Good Morning
>
> This is probably a troll,
If this actually is io_x, then he really believes this stuff.
> but it is a good opportunity to suggest to
> everyone who is tempted to argue about this issue to start from
> Dijkstra's paper rather than simply asserting that "goto is good"
> without understanding the issues involved.
>
> http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
> Harmful.html
And then read Knuth's "Structured Programming with go to Statements" (a bad
scan is here:
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf)
"... programmers and language designers still feel the need for some
euphemism that 'goes to' without saying 'go to' ..."
--
Bartc
Daniel T.
> I use goto to break nested for loops and I can't see a
> reason to ban goto.
I'll give you a reason to ban goto. This is a line of BASIC code:
90 x = 5
Now, I ask you, where is the line that was previously executed? Is it
directly above line 90, is it directly below it, or could it be anywhere
in the program? Because of the goto statement, simply because an
unstructured "goto" is possible in the language, you have to analyze the
entire program to know the answer. If we ban the use of "goto", we can
confidently know exactly what line of code comes before line 90.
Richard
"bartc" <ba...@freeuk.com> writes:
Recommending Knuth is like telling someone they need to qualify as a
NASA rocket scientist in order to fly a kite.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
bartc
Goto's at least are usually confined to the same function; if the function
is smallish, you don't have to look far to match a goto with a label.
Most languages will allow "x=5" inside a function; where is that function
called from? It could be from anywhere in hundreds of modules.
--
Bartc
Leigh Johnston
"Daniel T." <dani...@earthlink.net> wrote in message
news:daniel_t-DBCC13...@70-3-168-216.pools.spcsdns.net...
This channel is about C++ not BASIC, you do not have to analyze the entire
program in C++ as goto can only jump within the same function so comparisons
with BASIC is silly.
/Leigh
Kenny McCormack
Leigh Johnston <le...@i42.co.uk> wrote:
...
>This channel is about C++ not BASIC, you do not have to analyze the entire
>program in C++ as goto can only jump within the same function so comparisons
>with BASIC is silly.
(Channelling Kiki)
>This channel
channel???
>is about C++ not BASIC, you do not have to analyze the entire
C++ is not C (so says Kiki every chance he gets)
--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.
CLC in a nutshell.
Leigh Johnston
"Kenny McCormack" <gaz...@shell.xmission.com> wrote in message
news:hqv40l$oh$3...@news.xmission.com...
Sorry non-C++ folks I didn't spot the cross-post, I hate it when people do
that. At least what I said also applies to C.
/Leigh
Daniel T.
> "Daniel T." <dani...@earthlink.net> wrote:
> > Ali Karaali <ali...@gmail.com> wrote:
> >
> > > I use goto to break nested for loops and I can't see a
> > > reason to ban goto.
> >
> > I'll give you a reason to ban goto. This is a line of BASIC code:
> >
> > 90 x = 5
> >
> > Now, I ask you, where is the line that was previously executed? Is it
> > directly above line 90, is it directly below it, or could it be anywhere
> > in the program? Because of the goto statement, simply because an
> > unstructured "goto" is possible in the language, you have to analyze the
> > entire program to know the answer. If we ban the use of "goto", we can
> > confidently know exactly what line of code comes before line 90.
>
> This channel is about C++ not BASIC, you do not have to analyze the entire
> program in C++ as goto can only jump within the same function so comparisons
> with BASIC is silly.
I posted the message to the comp.programming and forgot to restrict the
groups.
In C and C++, goto is sufficiently restricted that as long as your
functions are small, it is largely harmless. In other words:
label:
x = 5
Where was the line previously executed? In C++ (and C) you don't need to
analyze the whole program to find the answer, you need only analyze the
function. As long as you keep functions small, the issue is minimized.
Daniel T.
> >
> > > I use goto to break nested for loops and I can't see a reason to
> > > ban goto.
> >
> > I'll give you a reason to ban goto. This is a line of BASIC code:
> >
> > 90 x = 5
> >
> > Now, I ask you, where is the line that was previously executed? Is
> > it directly above line 90, is it directly below it, or could it be
> > anywhere in the program? Because of the goto statement, simply
> > because an unstructured "goto" is possible in the language, you have
> > to analyze the entire program to know the answer. If we ban the use
> > of "goto", we can confidently know exactly what line of code comes
> > before line 90.
>
> Goto's at least are usually confined to the same function; if the
> function is smallish, you don't have to look far to match a goto with
> a label.
>
> Most languages will allow "x=5" inside a function; where is that
> function called from? It could be from anywhere in hundreds of modules.
As Dijkstra pointed out in "Go To Statement Considered Harmful"
As soon as we include in our language procedures we must admit that
a single textual index is no longer sufficient. In the case that a
textual index points to the interior of a procedure body the dynamic
progress is only characterized when we also give to which call of
the procedure we refer. With the inclusion of procedures we can
characterize the progress of the process via a sequence of textual
indices, the length of this sequence being equal to the dynamic
depth of procedure calling.
...
The main point is that the values of these indices are outside
programmer's control; they are generated (either by the write-up of
his program or by the dynamic evolution of the process) whether he
wishes or not. They provide independent coordinates in which to
describe the progress of the process.
Why do we need such independent coordinates? The reason is - and
this seems to be inherent to sequential processes - that we can
interpret the value of a variable only with respect to the progress
of the process. If we wish to count the number, n say, of people in
an initially empty room, we can achieve this by increasing n by one
whenever we see someone entering the room. In the in-between moment
that we have observed someone entering the room but have not yet
performed the subsequent increase of n, its value equals the number
of people in the room minus one!
The unbridled use of the go to statement has an immediate
consequence that it becomes terribly hard to find a meaningful set
of coordinates in which to describe the process progress. Usually,
people take into account as well the values of some well chosen
variables, but this is out of the question because it is relative to
the progress that the meaning of these values is to be understood!
With the go to statement one can, of course, still describe the
progress uniquely by a counter counting the number of actions
performed since program start (viz. a kind of normalized clock). The
difficulty is that such a coordinate, although unique, is utterly
unhelpful. In such a coordinate system it becomes an extremely
complicated affair to define all those points of progress where,
say, n equals the number of persons in the room minus one!
Your comparison between functions and goto has already shown to be
unfounded.
spinoza1111
wrote:
> In article <EIOdnQHlmcFTj07WnZ2dnUVZ8h-dn...@giganews.com>,Leigh Johnston <le...@i42.co.uk> wrote:
>
> ...
>
> >This channel is about C++ not BASIC, you do not have to analyze the entire
> >program in C++ as goto can only jump within the same function so comparisons
> >with BASIC is silly.
>
> (Channelling Kiki)
Shouldn't that be Mr. Thompson?
>
> >This channel
>
> channel???
More like Cartoon Network's Scoobie Doo Weekend.
>
> >is about C++ not BASIC, you do not have to analyze the entire
>
> C++ is not C (so says Kiki every chance he gets)
Surely you're shittin' me
Surely you jest
C plus plus not C?
Omigod is that on the test?
Surely that ole Kiki
Is a real giant brain
If he knows shit like that 'bout C
And how to code, int main()
Surely I'm not worthy
Surely I'm scum
Gotta listen to Kiki
Ooooooohhhh he makes me...get all excited or something...
Kiki made a wiki
On wikipedi-AH
About a god named tiki
And how to code in C-ah
But then an egregious Troll
Thought it would be Droll
To not call him Thompson
So Kiki got his machine gun
And he kilt the guy, Spinoza Ed
He kilt him so he was dead dead dead
This story has no moral
This story has no end
This story just goes to show
That Kiki's gone round the bend
(Dissolve to burning tires and dancing trolls)
spinoza1111
> "Daniel T." <danie...@earthlink.net> wrote in message
That's been UNTRUE about the only Basic left standing (Visual Basic)
for at least twenty years, pard. Basic programs can be written as a
single main() with go tos, but so can C programs. Either style of
coding is possible if one's an idiot savant, twisted sick freak,
moron, or down a quart or more on a couple of computer science
classes.
However, just like C, modern Basic includes Function and Sub
constructs and structured programming. Indeed, buy my book I need the
money; it is "Build Your Own .Net Language and Compiler" (Apress 2004)
and it includes a fully structured and OO compiler for much of Quick
Basic, organized into functions and written in Visual Basic 2003. I
don't recall using Go To at all.
(Anybody who writes a compiler in Basic, even modern, structured
Basic, should either have his head examined or win some sort of Geek O
Rama prize, but when I asked my technical editor if I could write it
in C Sharp he said no.)
>
> /Leigh
spinoza1111
> "Daniel T." <danie...@earthlink.net> wrote in message
>
> news:daniel_t-DBCC13...@70-3-168-216.pools.spcsdns.net...
>
> > Ali Karaali <ali...@gmail.com> wrote:
>
> >> I use goto to break nested for loops and I can't see a
> >> reason to ban goto.
>
> > I'll give you a reason to ban goto. This is a line of BASIC code:
>
> > 90 x = 5
>
> > Now, I ask you, where is the line that was previously executed? Is it
> > directly above line 90, is it directly below it, or could it be anywhere
> > in the program? Because of the goto statement, simply because an
> > unstructured "goto" is possible in the language, you have to analyze the
> > entire program to know the answer. If we ban the use of "goto", we can
> > confidently know exactly what line of code comes before line 90.
>
> Goto's at least are usually confined to the same function; if the function
> is smallish, you don't have to look far to match a goto with a label.
It's not a question of how far you have to look. It is a question of
minimal preconditions. If you have a go to even in a small program,
the code that follows it has a larger set of preconditions.
spinoza1111
Brilliant, couldn't say it any better.
Programming, and coding's laws lay hidden in night:
God said, let Dijkstra be! And all was Light.
DIJSTRA! thou shouldst be living at this hour:
CLC hath need of thee: she is a fen
Of stagnant waters: fighting about void main
Programmers, once proud of their might and power
Have forfeited their ancient English dower 5
Of simple competence. We are selfish men;
O raise us up, return to us again,
And give us manners, virtue, freedom, power!
Thy soul was like a Star, and dwelt apart;
Thou hadst a voice whose sound was like the sea: 10
Pure as the naked heavens, majestic, free,
So didst thou travel on life's common way,
In cheerful godliness; and yet thy heart
The lowliest duties on herself did lay:
Even business programming you deigned to address
And at assembling railway trains you were a success:
You showed us how to make sure the Loo
Was equidistant from each chap, in the choo choo. [1]
Come back into the building, Dijkstra, like a God
Returning to earth to redeem both wise man and Clod.
[1] EWD365: A Parable, at http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD365.html
Daniel T.
> > > Ali Karaali <ali...@gmail.com> wrote:
> >
> > > > I use goto to break nested for loops and I can't see a reason to
> > > > ban goto.
> > >
> > > I'll give you a reason to ban goto. This is a line of BASIC code:
> > >
> > > 90 x = 5
> > >
> > > Now, I ask you, where is the line that was previously executed? Is
> > > it directly above line 90, is it directly below it, or could it be
> > > anywhere in the program? Because of the goto statement, simply
> > > because an unstructured "goto" is possible in the language, you
> > > have to analyze the entire program to know the answer. If we ban
> > > the use of "goto", we can confidently know exactly what line of
> > > code comes before line 90.
> >
> > Goto's at least are usually confined to the same function; if the
> > function is smallish, you don't have to look far to match a goto
> > with a label.
>
> It's not a question of how far you have to look. It is a question of
> minimal preconditions. If you have a go to even in a small program,
> the code that follows it has a larger set of preconditions.
Could you go into more detail? Maybe with some examples?
io_x
"Mensanator" ha scritto nel messaggio
news:5fd893eb-9dda-4c70...@u34g2000yqu.googlegroups.com...
all programming is all about choose the right gotos
and how to write them in the page.
point, end of programming difficulies,
there is nothing to say
io_x
"Alexei A. Frounze" ha scritto nel messaggio
news:9aedd878-0ccc-4f4a...@m25g2000prj.googlegroups.com...
what does it mean "patterns"?
all programming is all about choose the right gotos
>Alex
io_x
Sorry i not have a computer science degree, i have a degree only
in math; possible i not merit it too, so possible
i not thought enough or not have the instruction
for speak about this argument.
[for instruction i mean study CS, math, phisic, history,
languages, biology, etc etc read books etc etc]
Hope so not to be in the ones that not understand problems
and propose not good solutions due his lack of think
to the argument or for not enough instruction
yes there are many ways, where will be the right way?
i'm just lazy
i'm not like you, all you
i think in how i can write something in less words possible
or in how beauty something in one page can be;
you can tell to "Bohm-Jacopini"
that, is not important where there are the enters
and where are the exits in a piece of code
the important is that all this is readable and followable
the important is that the eye can see all the code paths
and follow well what happen
for
here the readability is near to 0 because there is no indentation
not multi-line instructions
and because the assembly instructions are little
they have not need of big words
but they have need little len words
somethig like
<i
LBL1:
>i|i>=*limit#LBL19
...
cold be better traslated
push i
LBL1:
pop i|cmp i, [limit]|jGE LBL19
.
"mov eax, 19"
is not a big operation
not has need of big words
so could write it just as "a=19"
Assembly have one vantage too,
when write "mov eax, 19"
we know eax is a 32 bit register
instead in C or C++
"int a=19;"
and don't know how many bit are in "int"
io_x
"Ali Karaali" ha scritto nel messaggio
news:dda9d933-e9c1-418f...@r27g2000yqn.googlegroups.com...
>I use goto to break nested for loops and I can't see a
> reason to ban goto.
i would use goto or the asm extentions (jz, jnz, jnc, jc)
for all the programming
> Ali
Moi
IMHO the *readability* of "goto cleanup;" is not basically different
from a function call "do_cleanup();".
A function does not check its preconditions either.
In both cases the programmer can choose a name for the function or label.
And that name may or may not reflect its purpose.
AvK
Pascal J. Bourguignon
You have to EXECUTE the entire program before knowing where you came
from, thanks to computed GOTOs :-)
--
__Pascal Bourguignon__
Alexei A. Frounze
> "Alexei A. Frounze" ha scritto nel messaggionews:9aedd878-0ccc-4f4a...@m25g2000prj.googlegroups.com...
>
>
>
> >On Apr 24, 3:13 am, "io_x" <a...@b.c.invalid> wrote:
> >> [Xpost to: alt.comp.programming, alt.lang.asm,
> >> comp.lang.c, comp.lang.c++, comp.programming]
>
> >> the people that speak not good about "goto"
> >> are uttled wrong; their code bug full etc
>
> >> more distant is your code from goto
> >> more your code is bug full and incompresible
>
> >> the "goto" is the key word for programming;
> >> all the remain, other than goto or jmp or jc or jz,
> >> and the easy cpu layout
> >> is the wrong way for programming
>
> >> i advise all you
> >> Good Morning
> >Everything may be used, misused and abused, goto included. There are
> >good and bad usage patterns and goto is not an exception here. I can
> >list a number of other things that may be just as bad as a poorly used
> >goto (or as good as a good goto). See?
>
> what does it mean "patterns"?
Not sure what you mean here.
> all programming is all about choose the right gotos
If your programs consisted only of gotos (as I infer from the above),
they would be useless. Programming is not all about choosing the right
gotos. Less so all programming. It's about many more things.
Alex
Phil Carmody
> In article
> <dda9d933-e9c1-418f...@r27g2000yqn.googlegroups.com>,
> Ali Karaali <ali...@gmail.com> wrote:
>
>> I use goto to break nested for loops and I can't see a
>> reason to ban goto.
>>
>>
>> On 24 Nisan, 13:13, "io_x" <a...@b.c.invalid> wrote:
>> > [Xpost to: alt.comp.programming, alt.lang.asm,
>> > comp.lang.c, comp.lang.c++, comp.programming]
>> >
>> > the people that speak not good about "goto"
>> > are uttled wrong; their code bug full etc
>> >
>> > more distant is your code from goto
>> > more your code is bug full and incompresible
>> >
>> > the "goto" is the key word for programming;
>> > all the remain, other than goto or jmp or jc or jz,
>> > and the easy cpu layout
>> > is the wrong way for programming
>> >
>> > i advise all you
>> > Good Morning
>
I'm with Knuth. I've reviewed patches and told the submitter to
just convert all his jumble of 'structure' into nice clean goto
statements many times this year. I don't use it for my own code,
but $DAYJOB has a clear coding style that recommends goto in
many situations. If goto has made your function unreadable, it
was probably too big and unreadable anyway.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
James Kanze
wrote:
> Tim Streater <timstrea...@waitrose.com> writes:
> > I haven't used a goto since 1978 (when I stopped writing
> > FORTRAN).
Me neither.
> I'm with Knuth.
In other words, if goto makes the code simpler, it means that
you haven't found the correct expression of the algorithm.
And of course, the problem isn't with goto, per se. It's with
the way it is used. But because it can be abused so badly,
modern languages (including C and C++) provide all of the
necessary structures (and then some) so you don't have to use
it.
> I've reviewed patches and told the submitter to just convert
> all his jumble of 'structure' into nice clean goto statements
> many times this year. I don't use it for my own code, but
> $DAYJOB has a clear coding style that recommends goto in many
> situations. If goto has made your function unreadable, it was
> probably too big and unreadable anyway.
If goto seems necessary, it's because your function is too big
and unreadable.
--
James Kanze
Mensanator
> "Mensanator" ha scritto nel messaggionews:5fd893eb-9dda-4c70...@u34g2000yqu.googlegroups.com...
> On Apr 24, 5:13 am, "io_x" <a...@b.c.invalid> wrote:
>
>
>
>
>
> >> [Xpost to: alt.comp.programming, alt.lang.asm,
> >> comp.lang.c, comp.lang.c++, comp.programming]
>
> >> the people that speak not good about "goto"
> >> are uttled wrong; their code bug full etc
>
> >> more distant is your code from goto
> >> more your code is bug full and incompresible
>
> >> the "goto" is the key word for programming;
> >> all the remain, other than goto or jmp or jc or jz,
> >> and the easy cpu layout
> >> is the wrong way for programming
>
> >> i advise all you
> >> Good Morning
> >Yeah, there's nothing more fun than converting BASIC to Pascal.
>
> >Only to discover that goto was used to return from a sub-routine
> >without clearing the stack.
>
> all programming is all about choose the right gotos
No, it's not.
> and how to write them in the page.
Bullshit.
> point, end of programming difficulies,
You wish.
> there is nothing to say
Then why don't you shut up and quit saying it.
No one is interested in your prattle.
James Kanze
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> news:051fa27d-5cf8-4f7e...@g34g2000pro.googlegroups.com...
> > On Apr 24, 6:06 pm, Ali Karaali <ali...@gmail.com> wrote:
> >> I use goto to break nested for loops and I can't see a
> >> reason to ban goto.
> > 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.
But when do you have to break out of a nested loop? (And of
course, the only valid use of break in C++ is to end a case in a
switch. Otherwise, it's just a goto in disguise.)
--
James Kanze
James Kanze
> "Leigh Johnston" <le...@i42.co.uk> wrote:
[...]
> In C and C++, goto is sufficiently restricted that as long as
> your functions are small, it is largely harmless.
In C and C++, if your functions are small enough, goto is
largely harmless. And also useless. All of the examples I've
seen defending goto introduce excessively complex functions in
order to justify it.
--
James Kanze
James Kanze
wrote:
> "Alexei A. Frounze" <alexfrun...@gmail.com> writes:
[...]
> > Everything may be used, misused and abused, goto included.
> > There are good and bad usage patterns and goto is not an
> > exception here. I can list a number of other things that may
> > be just as bad as a poorly used goto (or as good as a good
> > goto). See?
Except that we're talking about C and C++ here, and in C and in
C++, for all "good" uses of goto (and a number of bad ones), the
language has specialized structures which better express the
meaning.
> Indeed. For example, the Duff device is worse than most gotos
> I've ever seen.
And it's fully structured:-).
Seriously, Duff himself said that it was an argument concerning
the way C implemented switch, but he wasn't sure whether it was
an argument for or against. (And it should probably be pointed
out that Duff used it to solve one very special problem, with
one specific compiler---his code almost certainly wouldn't work
correctly with any modern compiler.)
--
James Kanze
Pascal J. Bourguignon
Well, it would depend on the C standard (perhaps the later
specifications changed), but AFAIK, this is the way C is specified, and
the Duff device should work on all compliant compiler.
--
__Pascal Bourguignon__
Rod Pemberton
news:4bd2c215$0$1136$4faf...@reader1.news.tin.it...
> [Xpost to: alt.comp.programming, alt.lang.asm,
> comp.lang.c, comp.lang.c++, comp.programming]
>
> the people that speak not good about "goto"
> are uttled wrong; their code bug full etc
>
I learned structured programming concepts, just prior learning how to
program in an unstructured language: BASIC. So, I never had a problem with
GOTO's in BASIC. But, I knew someone who programmed in BASIC without using
structured programming concepts. He could code very quickly. But, every
now and then, he made a mistake. When he did, it was nearly impossible for
him to locate the incorrect code, typically an errant GOTO. He usually had
to delete his program and start again. For C, which has GOTO and structured
loops, I've only used GOTO once, for clarity.
From a certain perspective, needing "goto" is true, but only partially true.
All loops, control flow, etc., must be reduced to "goto" or "gosub", since
assembly only implements branches, jumps, calls, not higher level structured
loops. (x86 assembly is an exception, but the structured loop constructs
still aren't used...) So, from the perspective of assembly, goto's are
used. But, from a different perspective, BASIC or C, GOTO's cause problems.
They are unstructured. That means that a GOTO can branch out of one loop
and into another, intentionally or accidentally. Since most loops have a
loop variable or counter, this causes problems with a misplaced GOTO. The
jumped into loop may not terminate correctly. Adding to the problem, early
unstructured languages were line oriented. You could delete, insert, and
renumber lines. But, you had to manually correct the changed line number in
your GOTO's. I.e., you inserted line 32, had a GOTO from line 100 to line
35, after renumbering line 32 is 35 and 35 is 40, the GOTO still points to
line 35, i.e., formerly 32, when it should point to 40. So, structured
programming languages generally eliminate lines and line numbering.
Code that is hard to follow or fix because of haphazard use of GOTO's is
called "spaghetti code". Structured concepts fix this problem. They impose
a few rules and hide the GOTO's behind other language constructs: FOR,
DO-WHILE, WHILE, etc. Hiding GOTO's behind other language constructs
makes sure the use of GOTO's follows the rules for structured programming.
Structured programming generally requires a single entry and single exit
from any procedure or loop. The C language usually allows multiple exits
from it's procedures and loops. It's an exception when it comes to
structured programming languages. C doesn't support multiple entry, but
that can be simulated with constructs such as DUFF's device. However, C
still has GOTO. This allows for easy porting of code from other languages.
It's not needed to program. Using GOTO's in C, makes it *very* difficult to
restructure the flow of the program. GOTO can be used for speed improvement
to exit with many nested loops, but if the code was well written, the C
compiler's optimizer will generate just as efficient code without GOTO's.
It seems you stirred up the comp.lang.c, comp.lang.c++, crowds... I've
removed them from this post. I'm not interested in hearing from them that
my experience and knowledge is wrong.
Rod Pemberton
bartc
> On Apr 25, 12:27 am, "Daniel T." <danie...@earthlink.net> wrote:
>> "bartc" <ba...@freeuk.com> wrote:
>>> "Daniel T." <danie...@earthlink.net> wrote:
>>>> Ali Karaali <ali...@gmail.com> wrote:
>>
>>>>> I use goto to break nested for loops and I can't see a reason to
>>>>> ban goto.
>>>> 90 x = 5
>>
>>>> Now, I ask you, where is the line that was previously executed? Is
>>> Goto's at least are usually confined to the same function
>>> Most languages will allow "x=5" inside a function; where is that
>>> function called from?
>> As Dijkstra pointed out in "Go To Statement Considered Harmful"
>> As soon as we include in our language procedures we must admit that
>> a single textual index is no longer sufficient. In the case that a
....
>> Your comparison between functions and goto has already shown to be
>> unfounded.
>
> Brilliant, couldn't say it any better.
That's a shame, because I didn't understand a word of the Dijkstra extract.
--
Bartc
James Dow Allen
> ...
> everyone who is tempted to argue about this issue to start from
> Dijkstra's paper rather than simply asserting that "goto is good"
> without understanding the issues involved.
>
> http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
> Harmful.html
I did click the link, though I'm sure I'd read the paper a few times
earlier.
It has one key sentence which I think is now widely understood:
Edsger W. Dijkstra wrote:
> The unbridled use of the go to statement has an immediate consequence
> that it becomes terribly hard to find a meaningful set of coordinates
> in which to describe the process progress.
(Hmmm. Dijkstra *does* write "UNBRIDLED use of goto". Funny how that
disappears from the pedants' sound-bite summaries.)
Dijkstra speaks of "meaningful ... coordinates ... to describe ..."
I think that when state machines are implemented with goto's, the goto
*helps* to map such "coordinates": the transition rules move you to
state 36 so you ... GOTO state39!
One of my own goto's appears horrendous, but is actually just
a way to go to the appropriate progress point when the "meaningful
coordinates" have been established:
Pseudo-code comparison
http://fabpedigree.com/james/gotoalt.htm
Actual C code
http://fabpedigree.com/james/dbldum.htm
(Warning: if anyone *does* say anything good about my code,
it will be a first, and I'll probably faint from the exhiliration!)
> http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
> Harmful.html
PS: Your newswriter seems to have clipped the link, Daniel, which
I then had to hand-enter. I think Google Groups would have gotten
it right, so you may want to switch to that: :-)
> http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
James Dow Allen
James Dow Allen
> PS: Your newswriter seems to have clipped the link, Daniel, which
> I then had to hand-enter. I think Google Groups would have gotten
> it right, so you may want to switch to that: :-)
Yes, Google's link did work. And yes, it was tongue-in-cheek of
me to suggest you switch to Google. :-)
Nevertheless I will point out that some pedants delight in ranting
at every Google bug. When Google gets it right and their news
software doesn't, they seem to view the non-Google foibles as
"treasured souvenirs of a bygone superior era." :-)
Just saying.
Juha Nieminen
> I use goto to break nested for loops and I can't see a
> reason to ban goto.
No. The correct keyword for breaking out of nested loops (in C++) is
'return'. If you are using 'goto' for that purpose, you are doing it
wrong.
"It's not the same thing". Precisely. If you design your code such that
you can always use 'return' to break out of nested loops, it will become
cleaner and easier to understand.
I have been programming in C++ both professionally and as a hobby for
over 10 years, and I have never got into a situation where 'goto' would
have been a tempting alternative because of being a simpler and more
straightforward solution than something else. It just doesn't come up.
I don't remember ever having written a 'goto' in the last 10+ years.
It's not a question of banning 'goto'. There is no *need* for 'goto'.
And if you code in such way that you just don't need it, your code will
become cleaner in a completely natural way.
spinoza1111
For every go to there is a label. For each place that control "comes
from" there is a separate bundle of facts that cane be true.
Alexei A. Frounze
> On Apr 24, 10:26 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
>
> > Tim Streater <timstrea...@waitrose.com> writes:
> > > I haven't used a goto since 1978 (when I stopped writing
> > > FORTRAN).
>
> Me neither.
>
> > I'm with Knuth.
>
> In other words, if goto makes the code simpler, it means that
> you haven't found the correct expression of the algorithm.
>
> And of course, the problem isn't with goto, per se. It's with
> the way it is used. But because it can be abused so badly,
> modern languages (including C and C++) provide all of the
> necessary structures (and then some) so you don't have to use
> it.
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).
> > I've reviewed patches and told the submitter to just convert
> > all his jumble of 'structure' into nice clean goto statements
> > many times this year. I don't use it for my own code, but
> > $DAYJOB has a clear coding style that recommends goto in many
> > situations. If goto has made your function unreadable, it was
> > probably too big and unreadable anyway.
>
> If goto seems necessary, it's because your function is too big
> and unreadable.
But you don't want too many trivial functions either for you won't see
the forest behind the trees. There should be a certain balance,
subjective, of course, but it's not like goto's are evil no matter
what. If they are evil, let's remember about pointers, which require a
lot of care. And about horrible type conversions, where you can't even
safely compare a signed int and an unsigned int (which is an absurd
thing, IMO). And then about non-portable things, about implementation-
defined/specific and undefined behavior. Now we're talking. goto is
just nothing compared to all of that. :)
Alex
Alexei A. Frounze
> In comp.lang.c++ Ali Karaali <ali...@gmail.com> wrote:
>
> > I use goto to break nested for loops and I can't see a
> > reason to ban goto.
>
> No. The correct keyword for breaking out of nested loops (in C++) is
> 'return'. If you are using 'goto' for that purpose, you are doing it
> wrong.
Now, let's consider C (or C++ where this function has to explicitly
free up some used resources or do some other cleanup). The objects
won't get freed here automatically by the magic of the destructor call
generated for you by the C++ compiler. You could implement the cleanup
code in several places of that function as block operators ending with
a return, but very often these blocks are to a certain degree
duplicates of one another. And it's not just the source code bloat
that's bad, it's also us making a trap for ourselves because one day
we may modify the function and forget to modify one or more of these
cleanup block operators in it.
> "It's not the same thing". Precisely. If you design your code such that
> you can always use 'return' to break out of nested loops, it will become
> cleaner and easier to understand.
>
> I have been programming in C++ both professionally and as a hobby for
> over 10 years, and I have never got into a situation where 'goto' would
> have been a tempting alternative because of being a simpler and more
> straightforward solution than something else. It just doesn't come up.
> I don't remember ever having written a 'goto' in the last 10+ years.
>
> It's not a question of banning 'goto'. There is no *need* for 'goto'.
> And if you code in such way that you just don't need it, your code will
> become cleaner in a completely natural way.
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.
Alex
spinoza1111
> In comp.lang.c++ Ali Karaali <ali...@gmail.com> wrote:
>
> > I use goto to break nested for loops and I can't see a
> > reason to ban goto.
>
> No. The correct keyword for breaking out of nested loops (in C++) is
> 'return'. If you are using 'goto' for that purpose, you are doing it
> wrong.
Don't you mean "break"? Return exits the containing function and has
its place, certainly, under abnormal conditions. But break goes to the
statement following the loop and is considered acceptably structured
in reality, because it can be so readily simulated as I've shown using
a flag.
io_x
> "io_x" <a...@b.c.invalid> wrote in message
> Structured programming generally requires a single entry and single exit
> from any procedure or loop.
it should be for one loop one single entry but one or more exits
[at last for error code "more exits"]
> It seems you stirred up the comp.lang.c, comp.lang.c++, crowds... I've
> removed them from this post. I'm not interested in hearing from them that
> my experience and knowledge is wrong.
they not understand that all with goto is easy, easier than their
difficult way of describe one algorithm, and more flexible
Alexei A. Frounze
...
> used. But, from a different perspective, BASIC or C, GOTO's cause problems.
> They are unstructured. That means that a GOTO can branch out of one loop
> and into another, intentionally or accidentally. Since most loops have a
> loop variable or counter, this causes problems with a misplaced GOTO. The
> jumped into loop may not terminate correctly.
We can misplace and incorrectly reorder many things, not just goto's.
If you restrict the use of goto in C/C++ to several simple patterns
and write your code carefully, goto's aren't really a problem.
Alex
Alexei A. Frounze
> removed them from this post. I'm not interested in hearing from them that
> my experience and knowledge is wrong.
Stay away from purists and idealists, they are far too often too
strict and offer impractical advice. :)
I too have been bitten by those folks. That's not to say I didn't
learn anything from the experience -- I spent quite some time figuring
out proper C as per its standard and started coding more portably and
defensively (but that's a totally different story).
Alex
Nick Keighley
> "Daniel T." <danie...@earthlink.net> wrote in message
>
> news:daniel_t-DBCC13...@70-3-168-216.pools.spcsdns.net...
>
> > Ali Karaali <ali...@gmail.com> wrote:
>
> >> I use goto to break nested for loops and I can't see a
> >> reason to ban goto.
>
>
> > 90 x = 5
>
> > Now, I ask you, where is the line that was previously executed? Is it
> > directly above line 90, is it directly below it, or could it be anywhere
> > in the program? Because of the goto statement, simply because an
> > unstructured "goto" is possible in the language, you have to analyze the
> > entire program to know the answer. If we ban the use of "goto", we can
> > confidently know exactly what line of code comes before line 90.
>
> program in C++ as goto can only jump within the same function so comparisons
> with BASIC is silly.
there's longjmp
though even that can only jump upstack
spinoza1111
wrote:
Hmm, I never have to use longjmp, since I tend to factor more.
Factoring a problem is resisted in Amerikkkan programming because
Amerikkkan managers don't want employees to be "creative", and it
takes a minimal amount of creativity to create a new C function.
Employees who learn how to construct and manage large systems are
innately dangerous, since their knowledge might transfer to labor
union organization or political causes above the level of Tea Baggery.
This is why properly factored code that consists of properly
functionally bound units often ENRAGES managers, and programmers
alienated and dispirited by the corporate rat race.
If it contains small functions whose purpose can be expressed in a
well-constructed sentence it is an image of a decent society in a
society that thrives on exporting death and importing alienation.
It's ideologically safer to use slop programmerese such as "I don't
wanna call dis function in multiple cases becuz dat is bad" in order
to show you know your place in the pecking order.
The ideal program is a single main() routine that does everything: a
model of a Fascist society.
Ein reich! Ein Fuhrer!
Leigh Johnston
"James Kanze" <james...@gmail.com> wrote in message
news:f8ad45ef-b5e6-488c...@11g2000yqr.googlegroups.com...
I don't use goto much, I have just three uses of it in my entire codebase
and in all cases it is for breaking out of a nested control structure: two
are for exiting a switch inside a while loop and the other is exiting a
nested for loop. The alternative to using goto in these cases would involve
the creation of an extra exit flag that would have to be checked at each
level which is not always desirable.
/Leigh
Phil Carmody
> In comp.lang.c++ Ali Karaali <ali...@gmail.com> wrote:
>> I use goto to break nested for loops and I can't see a
>> reason to ban goto.
>
> No. The correct keyword for breaking out of nested loops (in C++) is
> 'return'. If you are using 'goto' for that purpose, you are doing it
> wrong.
This is a purely religious point of view.
> "It's not the same thing". Precisely. If you design your code such that
> you can always use 'return' to break out of nested loops, it will become
> cleaner and easier to understand.
In that case you have to pass all state into and out of the function
that performs the nested loop. That might be significantly less
efficient than just having all the state locally, such that the target
of a goto still has access to it all. Again, your point of view looks
religious and blinkered.
> I have been programming in C++ both professionally and as a hobby for
> over 10 years
One should never flaunt ones lack of experience in order to back up
ones argument.
Phil Carmody
> On Apr 24, 1:20 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
>> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
>> news:051fa27d-5cf8-4f7e...@g34g2000pro.googlegroups.com...
>
>> > On Apr 24, 6:06 pm, Ali Karaali <ali...@gmail.com> wrote:
>> >> I use goto to break nested for loops and I can't see a
>> >> reason to ban goto.
>
>> > 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.
>
> But when do you have to break out of a nested loop?
For the same reason you want to break out of a single loop.
Do you have issues with people breaking out of single loops?
> (And of
> course, the only valid use of break in C++ is to end a case in a
> switch. Otherwise, it's just a goto in disguise.)
What do you mean by 'otherwise' - even that's just a goto in disguise?
wolfgang kern
"io_x" wrote:
> [Xpost to: alt.comp.programming, alt.lang.asm,
> comp.lang.c, comp.lang.c++, comp.programming]
> the people that speak not good about "goto"
> are uttled wrong; their code bug full etc
> more distant is your code from goto
> more your code is bug full and incompresible
> the "goto" is the key word for programming;
> all the remain, other than goto or jmp or jc or jz,
> and the easy cpu layout
> is the wrong way for programming
Except that GOTO is a HLL keyword and I'm Asmist and
more machine-code oriented than concerned about needs
within abstract structured HLL-compilers, I see nothing
wrong with GOTO as long it does what a programmer want.
I once checked PowerBasic's GOTO and found it always
compiled a long (16:16) jump, even rare required.
But its syntax checker cried aloud if you tried to
jump out of a [FOR/IF/...]-struct with GOTO.
I don't know C/C+-, but what I see by disassembling their
resulting output seem to end up in heavy bloated code,
perhaps from using BREAK and GOTO within nested blocks,
which the compiler may grant with copying all required
code-trails (stack recover/cleanup) to every added path.
So in this aspect GOTO may be really not the best choice.
see me happy for I don't need to care this in my world :)
__
wolfgang (ALA)
Patricia Shanahan
...
> 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
Daniel T.
> On Apr 24, 9:10 pm, "Daniel T." <danie...@earthlink.net> wrote:
> > ...
> > everyone who is tempted to argue about this issue to start from
> > Dijkstra's paper rather than simply asserting that "goto is good"
> > without understanding the issues involved.
> >
> > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
> > Harmful.html
>
> I did click the link, though I'm sure I'd read the paper a few times
> earlier. It has one key sentence which I think is now widely
> understood: Edsger W. Dijkstra wrote:
> > The unbridled use of the go to statement has an immediate
> > consequence that it becomes terribly hard to find a meaningful set
> > of coordinates in which to describe the process progress.
>
> (Hmmm. Dijkstra *does* write "UNBRIDLED use of goto". Funny how that
> disappears from the pedants' sound-bite summaries.)
Agreed, and many also fail to notice that it is rather hard to use goto
in an "unbridled" fashion in C and C++.
> One of my own goto's appears horrendous, but is actually just a way to
> go to the appropriate progress point when the "meaningful coordinates"
> have been established:
> Pseudo-code comparison
> http://fabpedigree.com/james/gotoalt.htm
> Actual C code
> http://fabpedigree.com/james/dbldum.htm
>
> (Warning: if anyone *does* say anything good about my code, it will be
> a first, and I'll probably faint from the exhiliration!)
It looks as though you have implemented a depth first search. (If it
isn't a depth first search, then I'd say your code isn't readable.) That
said, I fully agree that your code is better than the psudo-code you
present in comparison (you call it "Tim's code".) However, there are
better ways of implementing depth first searches than either of the two
you present.
Phil Carmody
I'm not a java person at all, but from what I understand try-finally
doesn't do what I use goto for, namely error-path cleanup. If, according
to Sun, "the finally block always executes when the try block exits",
then it's not error-path clean-up at all - it's unconditional cleanup.
Which is completely not what you want in a function whose job is to
acquire a bunch of resources.
Patricia Shanahan
I should have mentioned the use of a catch block to deal with
error-specific clean-up. The finally block is, indeed, the place for
unconditional clean-up.
Of course, memory clean-up is not an issue in Java, but there are other
resources that need explicit handling.
Patricia
Keith H Duggar
The Kuzmin circle tracing algorithm is certainly not "excessively
complex" and is an (elegant) example of goto being /necessary/ to
to provide the optimal solution in some very real and important
scenarios. There was a moderated flame war about this nine months
ago culminating with these final posts
http://groups.google.com/group/comp.lang.c++.moderated/msg/3ac2368e485e740d
http://groups.google.com/group/comp.lang.c++.moderated/msg/5beca2fac77f7ab9
that empirically proved beyond any contestation at the time that
the goto version was optimal in some scenarios. All the source
code, scripts, etc are still available at
http://www.duggar.org/pub/code/circle/
to anyone who wishes to /rationally/ challenge the results with
empirical evidence. Otherwise continued unconditional anti-goto
preaching is simply anti-intellectual religion and certainly not
computer science.
Note these empirical results could (should?) have been "expected"
from the fact that Knuth already mathematically proved, decades
ago, that certain goto structures cannot be transformed into the
"structured" forms without introducing additional calculations or
code duplication both of which can be suboptimal on both old and
modern physical platforms not only on abstract computers.
Finally, if you do try and measure results note that the provided
code takes exceptional care when it comes to certain things that
to the naive might seem unimportant such as removal of constants,
randomization, control of inlining, avoidance of monolithic
compilation, etc. That is all /necessary/ for accurate profiling
which can be tricky to say the least. That was one source of the
disagreement in that original thread, ie one participant who
thought he was "all that" was simply ignorant of many of those
real world profiling and measurement considerations.
Subsequently I discussed that flame war with one of the worlds
genius compiler writers who confirmed the necessity of the inlining
etc controls explained above. However, he also added that in his
experience it is pointless to argue with the anti-goto mob because
it is a religion that ignores all inconvenient empirical evidence.
KHD
Nick
> 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
Dave Harris
> > 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.
James Van Buskirk
news:aab23e01-b4d4-44c4...@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
Alexei A. Frounze
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
Alexei A. Frounze
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
Patricia Shanahan
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
Nick
> On Apr 25, 8:52 am, Nick <3-nos...@temporary-address.org.uk> wrote:
>>
>> 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.
>
> 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;
> }
That's the sort of thing (the var loop) that I meant by playing around
with loops. That is just so much more confusing than:
/* framework that sets do_first, do_second and first_is_first from array */
if(do_first && first_is_first)
printf("block 1\n");
if(do_second)
printf("block 2\n");
if(do_first && !first_is_first)
printf("block 1\n");
Which is exactly the problem - this one is clear, but gets messy if
"block 1" is a few lines but not obviously a function. Yours avoids
that, but is far from clear at first sight why it's looping.
If I was going for a loop, I'd be far more likely to set those three
variables, as for the above code and then create another flag and do:
do_first_this_time = do_first && first_is_first;
for(;;) {
if(do_first_at_all)
printf("Block 1\n");
if(do_second) {
printf("Block 2\n");
do_second = false;
}
if(do_first && !first_is_first) {
do_first_this_time = true;
continue;
} else
break;
}
Yes, pretty hideous. I still prefer it to yours though!
Alexei A. Frounze
:)
Actually, there was some left-over from the previous attempt, so this
one is a tad more simple:
...
for (var = start, cnt = 1 + (start != stop);
cnt--;
var += stop - start)
{
if (var == 1) printf("block 1 ");
else if (var == 2) printf("block 2 ");
}
...
Alex
James Dow Allen
> James Dow Allen <jdallen2...@yahoo.com> wrote:
>> > understood: Edsger W. Dijkstra wrote:
> > > The unbridled use of the go to statement has an immediate
> > > consequence that it becomes terribly hard to find a meaningful set
> > > of coordinates in which to describe the process progress.
> .
> > (Hmmm. Dijkstra *does* write "UNBRIDLED use of goto". Funny how that
> > disappears from the pedants' sound-bite summaries.)
> Agreed, and many also fail to notice that it is rather hard to use goto
> in an "unbridled" fashion in C and C++.
Did you mean "bridled"? ... Since you were arguing against goto.
> .
> > One of my own goto's appears horrendous...
> >http://fabpedigree.com/james/dbldum.htm
> .
> It looks as though you have implemented a depth first search.
Yes. Or rather backtracking, which is DFS with a smidgen
of extra control logic. The problem specifics mean there's
3 or 4 "smidgens" of extra control logic here. And in my
comments I admit that there are better ways to deal with *simpler*
backtracking problems, and better ways to deal with *harder*
backtracking applications.
> ... I fully agree that your code is better than the psudo-code you
> present in comparison ...
Well, thanks for that! The side-by-side comparison clearly shows
that I use 1 goto and 1 for-loop to avoid 2 break's, 4 if's,
2 else's and 2 other minor defects. I'm not arguing that goto's
aren't bad, just that other things (break's, too many variables,
etc.) are also bad and one seeks compromise.
> there are better ways of implementing depth first searches
> than either of the two you present.
If you submit working code that runs slower than mine by no more
than 20%, I will show it at the website as "Daniel's structured
improvement." (Speed *is* important of course for the target
application.)
James
io_x
"wolfgang kern" <now...@never.at> ha scritto nel messaggio
news:hr1a9j$4qf$1...@newsreader2.utanet.at...
>
> "io_x" wrote:
>> [Xpost to: alt.comp.programming, alt.lang.asm,
>> comp.lang.c, comp.lang.c++, comp.programming]
>
>> the people that speak not good about "goto"
>> are uttled wrong; their code bug full etc
>
>> more distant is your code from goto
>> more your code is bug full and incompresible
>
>> the "goto" is the key word for programming;
>> all the remain, other than goto or jmp or jc or jz,
>> and the easy cpu layout
>> is the wrong way for programming
>
> Except that GOTO is a HLL keyword and I'm Asmist and
> more machine-code oriented than concerned about needs
> within abstract structured HLL-compilers, I see nothing
> wrong with GOTO as long it does what a programmer want.
you see all jmp, je, jc etc etc for me they are all gotos
> I once checked PowerBasic's GOTO and found it always
> compiled a long (16:16) jump, even rare required.
> But its syntax checker cried aloud if you tried to
> jump out of a [FOR/IF/...]-struct with GOTO.
i used when i were 12-13, Basic too the Basic for vic-20
i think it was not the way for programming well
> I don't know C/C+-, but what I see by disassembling their
> resulting output seem to end up in heavy bloated code,
> perhaps from using BREAK and GOTO within nested blocks,
> which the compiler may grant with copying all required
> code-trails (stack recover/cleanup) to every added path.
> So in this aspect GOTO may be really not the best choice.
if you see the asm, without the .c or .cpp line of the traslation
could be difficult to understand
> see me happy for I don't need to care this in my world :)
it is not possible that i wrote some functions easily
than in C or in C++, with not big time,
without the "gotos==very good"
> __
> wolfgang (ALA)
Rod Pemberton
>
> If you restrict the use of goto in C/C++ to several simple patterns
> and write your code carefully, goto's aren't really a problem.
>
But, are goto's of any advantage in C over other solutions? With
optimization and good code structuring, is there any place that a goto is
the best choice?
"break" and "continue" function like goto's - without needing goto labels...
If "break" is used with "while(0)" code block, it is functionally the same
as using a forward goto. "continue" can be used for a backward goto...
IMO, this means simple usage of goto is no better than using structured C
control flow. That leaves more complicated situations where goto might have
some advantage.
The most common arguments for their use is 1) to break out of multiple, say
three or more, nested loops or 2) error recovery. Status flags,
fall-through, using a switch, restructuring the code blocks, reducing the
number of loops, can all be used to fix such problems. Is there some
situation that really advantages a goto?...
C has a robust flow control syntax. About the only thing that can't be done
readily is to detect if a while() loop was executed. The need for this is
exceptionally rare, IMO. You could use status flags, at the expense of
another variable... But, it's handled easily by adding an if() around the
while() with the same set of conditions:
A)
while(conditions)
{
/* loop stuff */
}
/* did loop execute or not? */
B)
if(identical_conditions_as_while)
{
while(conditions)
{
/* loop stuff */
}
/* if here, loop executed because */
/* conditions of if() while() are the same*/
}
> ... several simple patterns ...
Like?
Rod Pemberton
Rui Maciel
> But, are goto's of any advantage in C over other solutions? With
> optimization and good code structuring, is there any place that a goto is
> the best choice?
Yes, finite state machines. You can do those by putting a switch() on a loop but in the end
that is nothing more than a crude hack used to desperately (and irrationally) avoid using
goto.
Rui Maciel
Robert Redelmeier
> But, are goto's of any advantage in C over other solutions?
> With optimization and good code structuring, is there any
> place that a goto is the best choice?
>
> "break" and "continue" function like goto's - without needing
> goto labels... If "break" is used with "while(0)" code
> block, it is functionally the same as using a forward goto.
> "continue" can be used for a backward goto...
>
> IMO, this means simple usage of goto is no better than using
> structured C control flow. That leaves more complicated
> situations where goto might have some advantage.
Precisely! In small [teaching] examples, GOTO looks obviously
messy, confusing, "jumpy" and what have you. IOW, harmful [Dijkstra]
But structure _does_not_ scale! One if..then..else or case()
looks great. But when you have them 9 deep they are marching off
the page (formatting is a big part of the additional clarity)
and [worse], a bug in the substructures has the potential to
mess up the overall control flow. Misnesting.
GOTO _is_ messy. But it scales -- just lookup the target in
the symbol table. You do _not_ need to parse or worry about
any intervening code.
As a concrete example of the unsung benefits of GOTO, please
consider a text editor with letter commands. In C you'd do
this as a case() or switch() statement. It will be huge since
each of the commands may be quite involved. A structural bug
in (a) could affect (b). The compile may catch some of these,
but cannot when they are "paired", even far apart. A compiler
should not be used as a debugging tool.
In ASM (or C if it'll do this), you'd implement via a jmp table
(`jmp [ebx]`) and terminate each of the letter functions with
`jmp keyloop`. Or the equivalent call [ebx]/ret. More or
less how the C compiler will code it anyways.
obTroll: In many ways, GOTO is reminiscent of the slightly
more recent calculator debate between fans of TI algebraic
notation and HP reverse polish notation.
-- Robert
cbcurl
Yes, in fact, that is what you have to do when implementing FSMs in
languages lacking goto, such as Java. A smart, optimizing compiler
might be able to optimize away the loop and the switch and replace it
with direct jumps.
Kenneth Brody
> io_x wrote:
>
[... "goto bad" ...]
>
> I see there is a small misconception in this issue. The only nasty thing that is usually
> said about goto is that it's use may end up generating code which isn't easy to read, to
> interpret and to follow.
[...]
I often use "goto" to make it easier to implement "only one return" in some
more complex functions, especially those that require some cleanup before
returning.
--
Kenneth Brody
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:59eed8de-fa97-42f9...@h16g2000prf.googlegroups.com...
>
>
>
> > If you restrict the use of goto in C/C++ to several simple patterns
> > and write your code carefully, goto's aren't really a problem.
>
> But, are goto's of any advantage in C over other solutions? With
> optimization and good code structuring, is there any place that a goto is
> the best choice?
>
> "break" and "continue" function like goto's - without needing goto labels...
> If "break" is used with "while(0)" code block, it is functionally the same
> as using a forward goto. "continue" can be used for a backward goto...
while(0 /*shouldn't it actually be 1 because with 0 it won't execute
even once*/) looks like a legitimate loop at first until you have
found that all the breaks out of it. What's worse it introduces an
extra nesting level, so, if there's another loop inside, breaking out
the inner one won't be as simple as still doing goto -- you'll still
have to implement some variables or whatnot in order to do what a
single goto would.
> IMO, this means simple usage of goto is no better than using structured C
> control flow. That leaves more complicated situations where goto might have
> some advantage.
>
> The most common arguments for their use is 1) to break out of multiple, say
> three or more, nested loops or 2) error recovery. Status flags,
> fall-through, using a switch, restructuring the code blocks, reducing the
> number of loops, can all be used to fix such problems. Is there some
> situation that really advantages a goto?...
I'm using goto almost exclusively for the above two scenarios. For
everything else its ifs and switches (and ?: at times).
> C has a robust flow control syntax. About the only thing that can't be done
> readily is to detect if a while() loop was executed. The need for this is
> exceptionally rare, IMO. You could use status flags, at the expense of
> another variable... But, it's handled easily by adding an if() around the
> while() with the same set of conditions:
Yeah. But if you're linearly searching for something, then you begin
with an invalid index or NULL pointer and after the loop you just
examine it and see whether it has become valid or not and you don't
always need an extra variable.
Alex
robin
news:dda9d933-e9c1-418f...@r27g2000yqn.googlegroups.com...
|I use goto to break nested for loops and I can't see a
| reason to ban goto.
Many languages provide a means of leaving loops
prematurely, and without the need to use GO TO.
PL/I, for instance, provides the LEAVE statement.
To skip the remainder of the statements in a loop
and to begin another iteration of the loop,
PL/I provides an ITERATE statement.
In both cases, you don't need to go looking for the
label where a GOTO might transfer control.
robin
>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
But they do require the introduction of additional labels.
As well, you have to go looking for the place where the GOTO
transfers.
Using a structured method (such as LEAVE in PL/I)
makes it obvious that the end of a particular loop is
where control resumes.
Rod Pemberton
On Apr 26, 2:06 am, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
>
> while(0 /*shouldn't it actually be 1 because with 0 it
> won't execute even once*/)
>
Eee... Good catch! Sorry, that doesn't work.
But, no, definately not "while(1)"... That'd would be a loop. How about
"do {} while(0)"... With a "break" or "continue", we should have a forward
or backward goto. If the "break" or "continue" is not executed, the entire
section only executes once, as if the "do {} while(0)" was not there.
Hopefully, that's correct this time?
:-)
Rod Pemberton
Esra Sdrawkcab
<red...@ev1.net.invalid> wrote:
[editor with key processing]
> In ASM (or C if it'll do this), you'd implement via a jmp table
> (`jmp [ebx]`) and terminate each of the letter functions with
> `jmp keyloop`. Or the equivalent call [ebx]/ret. More or
> less how the C compiler will code it anyways.
Pshurely 'call [ebx]' and end each section with 'ret', no goto required?
> obTroll: In many ways, GOTO is reminiscent of the slightly
> more recent calculator debate between fans of TI algebraic
> notation and HP reverse polish notation.
Damn, missed that!
betterTroll: what about Comefrom?
>
> -- Robert
>
Needs a CRLF in there?
--
Nuns! Nuns! Reverse
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:3175dd42-6ff2-452b...@t14g2000prm.googlegroups.com...
That (do {} while(0)) is a possibility and it is sometimes used for
other purposes. Also, you could just put a break at the end of
while(1)/for(;;)'s block.
Alex
Richard Bos
> PS: Your newswriter seems to have clipped the link, Daniel, which
> I then had to hand-enter. I think Google Groups would have gotten
> it right, so you may want to switch to that: :-)
> > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_=
> Harmful.html
Except, of course, that it doesn't. Quoted-illegible: Just Say No.
Richard
Richard Bos
> In other words, if goto makes the code simpler, it means that
> you haven't found the correct expression of the algorithm.
>
> And of course, the problem isn't with goto, per se. It's with
> the way it is used.
Those two statements are in contradiction.
And that says all you need to know about the argument that "goto is
eeeevviiiillll!!!!!"
Sheesh, next thing someone'll want to ban it "for the sake of our
chiiillldruuuunnn!!!!"
Richard
Richard Bos
[ Quoting Dijkstra's "Goto considered harmful": ]
> The unbridled use of the go to statement
This is the one thing which Dijkstra's editor (who wrote that headline),
the War-On-Goto lobby, and even Dijkstra himself in later years, seem to
have missed.
_Unbridled_.
The unbridled use of salt is also deadly to humans. We must ban it
outright.
Richard (takes a little salt, not a lot)
Keith H Duggar
Indeed. Unbridled water drinking can be fatal:
http://en.wikipedia.org/wiki/Water_intoxication
Pure water is dangerous and highly concentrated being 55 molar. Water
kills more than a million people per year, half of them children! How
can anyone stand for the unbridled use of water.
KHD
Juha Nieminen
> Now, let's consider C (or C++ where this function has to explicitly
> free up some used resources or do some other cleanup). The objects
> won't get freed here automatically by the magic of the destructor call
> generated for you by the C++ compiler.
Make a wild guess what is one of the reasons I don't like C.
Juha Nieminen
> On Apr 25, 1:09 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> In comp.lang.c++ Ali Karaali <ali...@gmail.com> wrote:
>>
>> > I use goto to break nested for loops and I can't see a
>> > reason to ban goto.
>>
>> No. The correct keyword for breaking out of nested loops (in C++) is
>> 'return'. If you are using 'goto' for that purpose, you are doing it
>> wrong.
>
> Don't you mean "break"?
Exactly how do you exit out of a set of nested loops with a "break"?
Juha Nieminen
> This is a purely religious point of view.
>
> One should never flaunt ones lack of experience in order to back up
> ones argument.
I prefer "a purely religious point of view" over insulting a person
you don't know anything about.
Richard Heathfield
I don't. I exit out of a set of nested loops using the conditions in the
loop controllers.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Juha Nieminen
>> Exactly how do you exit out of a set of nested loops with a "break"?
>
> I don't. I exit out of a set of nested loops using the conditions in the
> loop controllers.
The idea was to make the code simpler, cleaner and easier to follow, not
more complicated and contrived.
Richard Heathfield
Yes. That's precisely why I use the conditions in the loop controllers.
Daniel T.
Unbridled use of strychnine is deadly too, how much strychnine do you
take? The debate is not the false dichotomy that some try to make it out
to be.
Robert Redelmeier
> [editor with key processing]
> Pshurely 'call [ebx]' and end each section with 'ret', no goto required?
Certainly if you wish to reuse the commands between different
modes. Less if you are desparately counting cycles on an 8088
(jmp saves a jmp after the ret). Also less good if the key
never returns "exit".
>> obTroll: In many ways, GOTO is reminiscent of the slightly
>> more recent calculator debate between fans of TI algebraic
>> notation and HP reverse polish notation.
>
> Damn, missed that!
>
> betterTroll: what about Comefrom?
??? what is even slightly trollish about COMEFROM?
It is an obvious debugging tool with _plenty_ of
hardware support (brkpt instructions & debug registers).
If someone chooses to use COMEFROM in their code, they
must think their code has bugs. They would know :)
>> -- Robert
>>
> Needs a CRLF in there?
'dems fightin' words. You callin' me MS-DOSish :)
Yes, I realize \n is old-school correct from when people (incl
me) had real paper ttys. I tr to save readers an extra line on
their too-short read-boxes. (I normally run monitors in portrait
mode with 100+ lines).
-- Robert
>
Nathan Baker
news:hr8ak7$vhk$1...@speranza.aioe.org...
>
> modes. Less if you are desparately counting cycles on an 8088
> (jmp saves a jmp after the ret).
Don't you mean that a 'jmp' saves a 'ret' after a 'ret'??
For nested calls, the final call can be replaced by a jmp. E.g.:
,---
Afunc:
<misc. code & func calls>
call Zfunc
`---
replaced by...
,---
Afunc:
<misc. code & func calls>
jmp Zfunc
`---
Nathan.
Juha Nieminen
> Juha Nieminen wrote:
>> In comp.lang.c++ Richard Heathfield <r...@see.sig.invalid> wrote:
>>>> Exactly how do you exit out of a set of nested loops with a "break"?
>>> I don't. I exit out of a set of nested loops using the conditions in the
>>> loop controllers.
>>
>> The idea was to make the code simpler, cleaner and easier to follow, not
>> more complicated and contrived.
>
> Yes. That's precisely why I use the conditions in the loop controllers.
Care to show an actual example of your "simpler, cleaner and easier to
follow" version of exiting a nested loop by meddling with the loop
conditions instead of using 'return'? For example, modify the following
code to conform to your specifications:
Value_t* MyClass::findValue(const Value_t& value)
{
for(size_t xInd = 0; xInd < data.size(); ++xInd)
for(size_t yInd = 0; yInd < data[xInd].size(); ++yInd)
for(size_t zInd = 0; zInd < data[xInd][yInd].size(); ++zInd)
{
if(data[xInd][yInd][zInd] == value)
return &data[xInd][yInd][zInd];
}
return 0;
}
tonydee
> [...] in C and in
> C++, for all "good" uses of goto (and a number of bad ones), the
> language has specialized structures which better express the
> meaning.
Just not so. Much low-level state-based code is best expressed via
gotos. There are a couple hundred usages spread over 7 different
Boost libraries (as of 1.41). Have a look and you might find
something you think reasonable. Sometimes working too much in a
particular set of problem domains can either make it seem like goto
isn't beneficial, or make it completely obvious it is. Parsers are
one area where the uses are clear, for example: the boost regex
parser. Similarly, some lexers I've written have employed gotos
too... it's just cleaner. I'm pretty sure Walter Bright chipped in on
an argument like this a couple years back, also supporting some uses
of gotos... not somebody who's experience I'd challenge - will try to
dig up the reference if anyone cares....
Cheers,
Tony
Nick Keighley
> ralt...@xs4all.nl (Richard Bos) wrote:
digitalis is a poison and quite a lot of peopel take on the doctor's
advice
James Dow Allen
> In comp.lang.c++ Richard Heathfield <r...@see.sig.invalid> wrote:
I'll admit my C functions tend to be overly long, but, without
mentioning names, some C programmers seem to use functions that
tend to be overly short! When a slightly complicated code fragment
is posted, like Juha's though there are unrelated examples, an
oft-seen response is "break it into smaller functions." For example
foo() { for ... for ... for ...}
can be built from three functions like
foo1() { for ... foo2(); }
*That*'s a big reason why some programmers "never need to use goto."
> > Juha Nieminen wrote:
> >> The idea was to make the code simpler, cleaner and easier to follow, not
> >> more complicated and contrived.
> > Yes. That's precisely why I use the conditions in the loop controllers.
> ... For example, modify the following
> code to conform to your specifications:
> [ for ... for ... for ... if ... return ]
As Juha is well aware, it's possible to make the code conform
by making the for statements much more complicated.
But when one compares the code, before and after, it's hard
to see why anyone would prefer the complicated code unless
they just have a dogmatic aversion to inner-returns or gotos.
On Apr 28, 2:12 pm, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> Sometimes working too much in a
> particular set of problem domains can either make it seem like goto
> isn't beneficial, or make it completely obvious it is.
This is an important point. In some ways, my experience has
been fairly broad, but I've never written a real parser, a
database manager, an accounting program, or a serious user
interface! (Some who now laugh at my inexperience may not
have written state space searchers, hardware diagnostics,
compressors, kernels, graphic or image manipulations, etc.)
Different applications will lead to different coding
style choices.
James Dow Allen
Nick Keighley
check out Richard Heathfield's posting history he's a confirmed single-
entry-single-exit man (like spinoza). I don't happen to agree but
there's no point in arguing about it.