on goto
in [General Programming]
|
From: James Dow Allen on 19 May 2010 09:25 On May 19, 7:42 pm, "bart.c" <ba...(a)freeuk.com> wrote: > James Dow Allen wrote: > > Another grown man felt the need to post flowchart > > comparisons that blithely ignored that (A && B) > > is more "complicated" than (B). If it isn't clear what > > I'm driving at then run this code through your "tool": > > A = B ? C : D; > > > if (B) > > AA = C; > > else > > AA = D; > > If your tool tells you the first form above is simpler, > > would you agree the tool is flawed? > > AA? ??? Yourself! The (irrelevant) use of an alternate name was just so no smart-aleck would argue that the first statement gets optimized out! > Whether A or AA, this potentially complex term has to be repeated. This form > also encourages you to spread it over 4 lines instead of 1, which can have > the effect of expanding the surrounding statement or function enough to make > it harder to take in at a glance. You miss the point. Of course I am *NOT* arguing against the simpler expression here, just pointing out that a conditional is a conditional whether it uses the keystrokes "if", "?:" or even "&&". I was rebutting another poster who claims that his *more* complicated code is, instead *equally* complicated just because *his tool* treats (A && B) and (B) as *equally* complicated*, even though the tool recognizes "if" as complicating. I hope my point isn't too ... er ... complicated :-) James
From: S Perryman on 19 May 2010 12:41 James Dow Allen wrote: > On May 17, 6:03 pm, S Perryman <q...(a)q.net> wrote: >>#1 does not appear to be that difficult to understand. > Sorry to repeat myself here (although that hasn't stopped > some of the rest of you :-) but this whole dialog continues > to stagger my imagination! > No, #1 isn't "too difficult" to understand ... but it *is* > more difficult than the simpler, more obvious approach. Didn't say it otherwise. > Another grown man felt the need to post flowchart > comparisons that blithely ignored that (A && B) > is more "complicated" than (B). Perhaps so, but *completely irrelevant* to my posting. Which was to show single entry single exit versions of the original function to compare and contrast. None of which required changing the existing loops to allow clean exit when the item was found. Nor having the runtime overhead of evaluating flags, computing other conditions etc to ensure clean exit. Regards, Steven Perryman
From: James Dow Allen on 19 May 2010 13:53 On May 19, 11:41 pm, S Perryman wrote: > James Dow Allen wrote: > > No, #1 isn't "too difficult" to understand ... but it *is* > > more difficult than the simpler, more obvious approach. > > Didn't say it otherwise.... > ... to show single entry single exit versions of the original > function to compare and contrast. So we agree. Your code was less readable than the simpler version, but was just intended as an existence proof. Fine. > > Another grown man felt the need to post flowchart > > comparisons that blithely ignored that (A && B) > > is more "complicated" than (B). > > Perhaps so, but *completely irrelevant* to my posting. *Of course* it was irrelevant! :confused: This isn't directed at you specifically, Mr. Perryman, but why is that the poster whose Message ID is in the References: line, feels the need to take any response, even when irrelevant, defensively??? I guess you're saying I should have written two *very* short messages, instead of one short message, so that I could have a separate specific reference for the "other grown man"; is that it? I prefer to think we're all friends here and are trying to exchange views informally, not engaging in personal debate. Do I have that wrong? James
From: S Perryman on 19 May 2010 14:22 James Dow Allen wrote: > So we agree. Your code was less readable than the simpler version No. Equally as readable, more verbose (IMHO) . Of course I am operating on a general premise that increased verbosity does not imply decreased readability. > but was just intended as an existence proof. Intended more as demonstration that : 1. the oft-stated method of coding loops (especially nested ones) in single entry single entry mode, is not the only method available 2. single entry single exit loops do not imply performance decreases > This isn't directed at you specifically, Mr. Perryman, > but why is that the poster whose Message ID is in the > References: line, feels the need to take any response, > even when irrelevant, defensively??? > I guess you're saying I should have written two *very* > short messages, instead of one short message, so that > I could have a separate specific reference for the > "other grown man"; is that it? Single reply (to) single poster ... Regards, Steven Perryman
From: Nick on 20 May 2010 03:00
Richard Heathfield <rjh(a)see.sig.invalid> writes: > Lie Ryan wrote: > <snip> > >> >> If I'm searching for all cells whose sprite size is 56 pixels (e.g. >> 7x8), do I create a list of all integers in the program? > > If sprite size matters to you, it makes sense to have a list of > (probably pointers to) sprites, sorted by sprite size. Instead of > searching cell by cell, you find the sprites that are the right size, > and then look at where they're displayed. That will be a darn sight > faster than iterating over your entire screen checking every pixel. Except, of course, as we all really know, there will be times when you just occasionally need to do something - perhaps when printing debugging information - that you otherwise have no need to. Creating multiple indexes on every field in a complex tree of structures for example, just in case you ever want to check any one of them for any particular value, even when written out in Sanskrit, seems overkill to me. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk |