on goto
in [General Programming]
|
From: Richard Heathfield on 11 May 2010 04:26 Seebs wrote: > On 2010-05-11, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Seebs wrote: >>> I'm working on a roguelike game. I have a dungeon, which consists of levels, >>> and the levels are not necessarily all the same size. Each level is itself >>> a 2D grid of points. It is quite conceivable to want to ask the question >>> "is there any point in the dungeon which contains a foo". At this point, >>> the obvious thing to do is >>> for each level >>> for each row >>> for each column >>> is there a foo? > >> No, that's a terrible way to do it. > >> You already have a list of foos, properly ordered for fast searching. > > No, I don't. Then I suggest you get one. > Why are you running a binary search on this specific array to see whether > an integer is found in it? You already have a list of integers, properly > ordered for fast searching; just run through that list and then find out > which array the integer you want is contained in. That's precisely why I'm running a *binary* search on this specific array. Maybe it's my fault, but I'm not seeing your point here. I originally advocated searching a properly sorted data structure instead of a brute force search, and you seem to be asking me why I'm doing that instead of... doing that. > > .... or don't. > >> If you don't already have a list of foos, then you are excusing one flaw >> in your program by the existence of another flaw in your program. Two >> bugs don't make a sensible programming strategy. > > I disagree. It is not at all obvious that "foo" is necessarily a type of > thing that ought to have a central list. When doing a model of a world, > it is quite often the case that there are many hundreds of types of objects > which might exist, and each location has a list of the objects it contains. > A single centrally sorted list of all the objects of each type would be > ludicrous. A single centrally sorted list of all the objects which exist > anywhere would be of extremely marginal utility. In particular, for the > case of, say, a roguelike game which includes multiple dungeons, searching > a given dungeon (using the nested loop) would be orders of magnitude faster > than searching a complete list of every object stored anywhere in the game. Let's think about that, shall we? The original 3-nested loop was looking for a particular object in, presumably, 3-D space. Let us be kind and assume that the search was already localised to a particular dungeon. So presumably we're looking at a 3D version of Rogue, where objects might be on a shelf, or dangling from the ceiling, or perhaps currently in flight. Let us assume further that our location co-ordinates have a granularity of one foot. We imagine a dungeon 10' tall, with floor dimensions 20' times 30'. That's 6,000 cells to search. Searching every cell until we find (or fail to find) the object involves an average search of 3,000 cells. When the object isn't present, we have to search the whole space - 6,000 cells. We're looking for a treasure chest. We could have a list of objects and their locations. We could index that list in various ways, one of which is by object, dungeon, and location within the dungeon. For the brute force search to be more efficient, log2(number of treasure chests) would have to exceed 3,000. You wouldn't be able to chuck a brick without hitting at least a million chests. > > In short: > > It depends. There exist problem spaces for which a nested search really is > the right tool. There exist others for which it isn't. I think you have yet to demonstrate a problem space where a nested search really is the right tool. That is not to say that no such problem space exists, however, and I am prepared to grant that it /does/ exist. But, in solving that problem, I would still stick to my style rule, because I find it easier to read SESE code than I do to read SEME code. > Dogmatically > asserting that every problem for which a nested loop is the best solution > exists only because of some other arbitrary flaw is pointless. I don't recall making any dogmatic assertions about nested loops, and I certainly don't recall using the word "every" in such a context. Are you sure you're not trying to extend my position? > We might > as well point out that English is absolutely the clearest and most expressive > language, because anyone who wants to say something which is not most clearly > expressed in English is clearly saying something stupid. Actually, well-written C is much clearer than well-written English. I would accept that it is not always quite so expressive, though. :-) -- 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
From: Richard Heathfield on 11 May 2010 04:28 Nick Keighley wrote: > On 11 May, 06:26, Richard Heathfield <r...(a)see.sig.invalid> wrote: > >> My preference for SESE is rooted in some truly appalling SEME >> code that I've had to maintain in the past. > > but MEME is even *more* fun. But that needs a truly awesome assemly > programmer. Well, no - but I think it does at least require a goto. -- 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
From: Alexei A. Frounze on 11 May 2010 04:54 On May 11, 12:55 am, "wolfgang kern" <nowh...(a)never.at> wrote: > Nathan Baker wrote: > >> Ok Nate, we had enough discussions on this matter since HLLs > >> entered our progamming world ... > >> We better give up arguing and let the 'faster' programmers > >> be proud of their 'maintainable/foolproof-readable' sources > >> which are awful detours with "abstraction layers" while the > >> few hardware freaks like me work on "really existing things" :) > > The CPU experiences a nightmare while executing HLL code. > > Perhaps there is an instructive way for us to demonstrate this fact? > > Even we could try this one more time, I daubt that > 'fundamental' HLL-coders may listen at all. > The believe in their holy compilers seem to be very strong :) > > I think demonstration of the bloated redundance isn't required, > disassemble whatsoever you find (windoze+lunix/app+sys) and > see as of immediate all the weird detours created by 'a tool'. > > The few programmers who know both worlds may be aware and > create lesser bloated and faster code even with HLL. There are several reasons for what you call compiler-produced bloat: - copy-pasted code at the source level (can happen in asm too) - duplicate functionality and data in different parts of big applications (can happen in asm too) - overly complicated code (can happen in asm too) - dead code and data (can happen in asm too) - error handling code (you probably need it in asm too) - use of macros, inlining and templates (macros exist in asm too) - calling convention support code for interoperation, variable argument subroutines, exception handling and debugging (you may need or want some of them in asm too) - code alignment (you may need it in asm too) - inadequately chosen optimization switches or speed preference over size - global variables, including not tightly packed structures (you may want data alignment in asm too) So, some of it comes from bad or complex source code, some from the fact that applications are made from many different parts done independently by different people, some is dictated by the overall API design and some from how the compiler and linker are used. Then again, often times quickly making software is more important than making it fast or small or both. Depends on the business model, which you may be unable to change other than by quitting your employer and finding a "better" one or starting your own company or simply going self- employed. I'm just explaining how this bloat is possible and expected. Alex
From: Richard on 11 May 2010 08:53 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-05-11, Daniel T. <daniel_t(a)earthlink.net> wrote: >> Seebs <usenet-nospam(a)seebs.net> wrote: >>> What if "foo" isn't a "MOB"? What if "foo" is a kind of a thing of which >>> there is no master list, just a list associated with each location? > >> Someone else is already beating you up on this one, so I'll just say >> this... "What if the situation is exactly such that the best solution is >> nested for loops and an early return?" To that I answer, then use nested >> for loops and an early return. What is your point? > > My point is: In the case where that loop would have been written at all, > the multiple-exit variant would be by far the cleanest solution. Every > alternative provided has either been noticably more complex, or been > reliant on an obviously-different data structure than the original addressed. > > I think in this case I'm pretty much in agreement with you on the issue; > the correct thing to do is make a decision in each case based on the > circumstances at hand. You don't say? You agree that the solution should match the problem? That's big of you Seebs! I am sure we are all hugely impressed by your willingness to accept that the solution can be optimised to the problem ..... > > My objection is to having people invent things ("you look through the list > of foos") which presume a wildly different data structure than had been > suggested. Erm, you mentioned foos too. (Side note : it is stupid to use "foo" and "bar" in examples when something far more tangible and real world would be so much cleaner and understandable). > >> My observation is that people often get caught up working at much too >> low a level than they should, and depending on what problem is being >> solved, code like the nested for loop example we have been discussing is >> indicative of that sort of thinking. > > That's a good point. I have certainly seen such loops which were indubitably > a result of bad planning. Like in your example for instance? > > I guess, offered as "this will necessarily work as a replacement", I find > most of the replacements unappealing. Offered as "this is enough prettier > that perhaps the data should be structured to suit it", many of them might > be a step forwards... Depending, of course, on the specific data. > > -s of course ... -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Richard on 11 May 2010 08:55
Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> writes: > Seebs <usenet-nospam(a)seebs.net> writes: >> On 2010-05-11, Keith Thompson <kst-u(a)mib.org> wrote: >>> "Daniel T." <daniel_t(a)earthlink.net> writes: >>>> Seebs <usenet-nospam(a)seebs.net> wrote: >>>>> I'm working on a roguelike game. I have a dungeon, which consists of >>>>> levels, and the levels are not necessarily all the same size. Each >>>>> level is itself a 2D grid of points. It is quite conceivable to want >>>>> to ask the question "is there any point in the dungeon which contains >>>>> a foo". At this point, the obvious thing to do is >>>>> for each level >>>>> for each row >>>>> for each column >>>>> is there a foo? >> >>>> I disagree. The obvious thing is to go through your list of MOB's and >>>> see if any of them are foos. Your list of MOB's will likely be a 1D >>>> vector or linked list. At most you have a list of MOB's per level and >>>> even there, each level will be encapsulated. Essentially a recursive >>>> algorithm. >> >>> What's a MOB? >> >> In many computer games, creatures are called "mobs" (short for mobiles, >> because they can move). > > Down staircases are not usually mobile, and I was searching for the > down staircase. > >> It's probably incorrect to turn it into block >> caps, since the word did not originate as an initialism, but I could make >> sense of it in context. (It's definitely incorrect to put an apostrophe >> on the plural, though.) > > I think the ggpp was just trying to blag that he was familiar > with the field in question, and therefore his view must carry > more weight about implementation issues. Is there a commonly- > named logical fallacy for misdirection through use of jargon? > > Phil There was no misdirection. Just a better algorithm. Sheesh. Hopefully the c++ and programming groups can draw their own conclusion of the "regs" who "contributed" the last three posts to this thread prior to myself. Petty nitpicking and clique like back slapping at the expense of real work practical application of C. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c |