on goto
in [General Programming]
|
From: Daniel T. on 29 Apr 2010 08:57 Tim Rentsch <txr(a)alumni.caltech.edu> wrote: > Keith H Duggar <duggar(a)alum.mit.edu> writes: > > > ... 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. > > Essentially the same thing could be said of the pro-goto mob. I think there are few people that are either anti-, or pro-, goto (and I try to avoid discussing the issue with those types of people.) To me 'goto' is very powerful, versatile tool. As the person who started this thread pointed out, programs can be written using goto instead of loops, exceptions and functions, and a whole host of other specialized control flow features that some languages possess. However, it is that versatility that makes things difficult. When goto is used, it can sometimes be confusing to the reader what the writer was trying to accomplish. As an analogy, if I am using a screwdriver, you can be sure that I am trying to turn a screw, if I am using a can opener you can be sure I'm trying to open a can, but if I'm using a swiss army knife, you can't be sure what it is I'm trying to accomplish without further study. However, if a corkscrew isn't available, then the swiss army knife is invaluable.
From: Jeff Flinn on 29 Apr 2010 09:26 Keith Thompson wrote: > Jeff Flinn <TriumphSprint2000(a)hotmail.com> writes: >> Keith Thompson wrote: >>> Seebs <usenet-nospam(a)seebs.net> writes: >>>> On 2010-04-28, bart.c <bartc(a)freeuk.com> wrote: >>>>> int* findvalue(int value) >>>>> {int *a=0; >>>>> >>>>> for(int xInd = 0; !a && xInd < datasize; ++xInd) >>>>> for(int yInd = 0; !a && yInd < dataxindsize; ++yInd) >>>>> for(int zInd = 0; !a && zInd < dataxindyindsize; ++zInd) >>>>> { >>>>> if(data[xInd][yInd][zInd] == value) >>>>> a=&data[xInd][yInd][zInd]; >>>>> } >>>>> >>>>> return a; >>>>> } >>>> This is noticably slower and less clear. I would not consider it >>>> an acceptable rewrite -- but I would consider the other form a good >>>> rewrite of it. >>> I mostly agree, but -- "noticably slower"? How did you notice? >> Certainly is for the case data[0][0][0] == value. ;-) > > How so? > > I'm not arguing that it's not *likely* to be slower, but (a) it's not > likely to be *noticeably* slower unless the entire loop is executed many > many times, and (b) it might not be slower at all, depending on how > clever the compiler is. > > (I'm assuming there's not some semantic difference that I haven't > noticed.) Have you profiled your 'assign address' version versus the previous 'return when found' version? For different sizes? The 'assign address' version is effectively doing a std::for_each, alway visiting every element even if the item found is the 1st one. The 'return when found' version is analogous to std::find_if. For the case data[0][0][0] == value, your algorithm is O(N), while find_if, is O(1). Jeff
From: Keith Thompson on 29 Apr 2010 12:12 Jeff Flinn <TriumphSprint2000(a)hotmail.com> writes: > Keith Thompson wrote: >> Jeff Flinn <TriumphSprint2000(a)hotmail.com> writes: >>> Keith Thompson wrote: >>>> Seebs <usenet-nospam(a)seebs.net> writes: >>>>> On 2010-04-28, bart.c <bartc(a)freeuk.com> wrote: >>>>>> int* findvalue(int value) >>>>>> {int *a=0; >>>>>> >>>>>> for(int xInd = 0; !a && xInd < datasize; ++xInd) >>>>>> for(int yInd = 0; !a && yInd < dataxindsize; ++yInd) >>>>>> for(int zInd = 0; !a && zInd < dataxindyindsize; ++zInd) >>>>>> { >>>>>> if(data[xInd][yInd][zInd] == value) >>>>>> a=&data[xInd][yInd][zInd]; >>>>>> } >>>>>> >>>>>> return a; >>>>>> } >>>>> This is noticably slower and less clear. I would not consider it >>>>> an acceptable rewrite -- but I would consider the other form a good >>>>> rewrite of it. >>>> I mostly agree, but -- "noticably slower"? How did you notice? >>> Certainly is for the case data[0][0][0] == value. ;-) >> >> How so? >> >> I'm not arguing that it's not *likely* to be slower, but (a) it's not >> likely to be *noticeably* slower unless the entire loop is executed many >> many times, and (b) it might not be slower at all, depending on how >> clever the compiler is. >> >> (I'm assuming there's not some semantic difference that I haven't >> noticed.) > > Have you profiled your 'assign address' version versus the previous > 'return when found' version? For different sizes? The 'assign address' > version is effectively doing a std::for_each, alway visiting every > element even if the item found is the 1st one. The 'return when found' > version is analogous to std::find_if. For the case data[0][0][0] == > value, your algorithm is O(N), while find_if, is O(1). Please look again. I'm fairly sure that all the versions I've seen in this thread terminate after finding the item. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Nick on 29 Apr 2010 14:26 Keith Thompson <kst-u(a)mib.org> writes: > Seebs <usenet-nospam(a)seebs.net> writes: >> On 2010-04-28, bart.c <bartc(a)freeuk.com> wrote: >>> int* findvalue(int value) >>> {int *a=0; >>> >>> for(int xInd = 0; !a && xInd < datasize; ++xInd) >>> for(int yInd = 0; !a && yInd < dataxindsize; ++yInd) >>> for(int zInd = 0; !a && zInd < dataxindyindsize; ++zInd) >>> { >>> if(data[xInd][yInd][zInd] == value) >>> a=&data[xInd][yInd][zInd]; >>> } >>> >>> return a; >>> } >> >> This is noticably slower and less clear. I would not consider it >> an acceptable rewrite -- but I would consider the other form a good >> rewrite of it. > > I mostly agree, but -- "noticably slower"? How did you notice? Certainly a /lot/ slower if the "sizes" are large, data[0][0][0] is 0 and the search value is zero ... -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
From: Nick on 29 Apr 2010 14:27
Keith Thompson <kst-u(a)mib.org> writes: > Jeff Flinn <TriumphSprint2000(a)hotmail.com> writes: >> Keith Thompson wrote: >>> Jeff Flinn <TriumphSprint2000(a)hotmail.com> writes: >>>> Keith Thompson wrote: >>>>> Seebs <usenet-nospam(a)seebs.net> writes: >>>>>> On 2010-04-28, bart.c <bartc(a)freeuk.com> wrote: >>>>>>> int* findvalue(int value) >>>>>>> {int *a=0; >>>>>>> >>>>>>> for(int xInd = 0; !a && xInd < datasize; ++xInd) >>>>>>> for(int yInd = 0; !a && yInd < dataxindsize; ++yInd) >>>>>>> for(int zInd = 0; !a && zInd < dataxindyindsize; ++zInd) >>>>>>> { >>>>>>> if(data[xInd][yInd][zInd] == value) >>>>>>> a=&data[xInd][yInd][zInd]; >>>>>>> } >>>>>>> >>>>>>> return a; >>>>>>> } >>>>>> This is noticably slower and less clear. I would not consider it >>>>>> an acceptable rewrite -- but I would consider the other form a good >>>>>> rewrite of it. >>>>> I mostly agree, but -- "noticably slower"? How did you notice? >>>> Certainly is for the case data[0][0][0] == value. ;-) >>> >>> How so? >>> >>> I'm not arguing that it's not *likely* to be slower, but (a) it's not >>> likely to be *noticeably* slower unless the entire loop is executed many >>> many times, and (b) it might not be slower at all, depending on how >>> clever the compiler is. >>> >>> (I'm assuming there's not some semantic difference that I haven't >>> noticed.) >> >> Have you profiled your 'assign address' version versus the previous >> 'return when found' version? For different sizes? The 'assign address' >> version is effectively doing a std::for_each, alway visiting every >> element even if the item found is the 1st one. The 'return when found' >> version is analogous to std::find_if. For the case data[0][0][0] == >> value, your algorithm is O(N), while find_if, is O(1). > > Please look again. I'm fairly sure that all the versions I've seen in > this thread terminate after finding the item. Not when the item is zero, because that's the "nothing has been found yet" flag, so the search executes to exhaustion even if the item was found hours ago. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk |