on goto
in [General Programming]
|
From: Leigh Johnston on 24 Apr 2010 11:54 "Kenny McCormack" <gazelle(a)shell.xmission.com> wrote in message news:hqv40l$oh$3(a)news.xmission.com... > In article <EIOdnQHlmcFTj07WnZ2dnUVZ8h-dnZ2d(a)giganews.com>, > Leigh Johnston <leigh(a)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. > 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
From: Daniel T. on 24 Apr 2010 12:12 "Leigh Johnston" <leigh(a)i42.co.uk> wrote: > "Daniel T." <daniel_t(a)earthlink.net> wrote: > > Ali Karaali <alicpp(a)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.
From: spinoza1111 on 24 Apr 2010 12:49 On Apr 25, 12:27 am, "Daniel T." <danie...(a)earthlink.net> wrote: > "bartc" <ba...(a)freeuk.com> wrote: > > "Daniel T." <danie...(a)earthlink.net> wrote: > > > Ali Karaali <ali...(a)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. > > > 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. 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
From: Daniel T. on 24 Apr 2010 12:27 "bartc" <bartc(a)freeuk.com> wrote: > "Daniel T." <daniel_t(a)earthlink.net> wrote: > > Ali Karaali <alicpp(a)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. > > 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.
From: spinoza1111 on 24 Apr 2010 12:38
On Apr 24, 11:46 pm, "bartc" <ba...(a)freeuk.com> wrote: > "Daniel T." <danie...(a)earthlink.net> wrote in message > > news:daniel_t-DBCC13.11141024042010(a)70-3-168-216.pools.spcsdns.net... > > > Ali Karaali <ali...(a)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. > > 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 |