on goto
in [General Programming]
|
From: Richard Heathfield on 12 May 2010 07:34 pete wrote: <snip> > > I find SEME to be less objectionable in functions > which are small enough so that you can't look at one exit > without noticing the all the rest of the exits. Yes, I'd agree that this is significantly less objectionable, provided there's an obvious pattern that links all the returns. (Note that our original 3D loop example more or less falls into this category.) -- 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 12 May 2010 07:36 James Dow Allen wrote: <snip> > But let's agree that much of this is a matter of taste. > I like Ernest Hemingway: >> Nick stood up. He was all right. > > Perhaps Mr. Heathfield prefers Joseph Conrad, who I > find almost unreadable. Actually, I prefer Tolkien. But then I don't have to maintain "Lord of the Rings". -- 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 12 May 2010 07:39 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. -- 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: Ben Bacarisse on 12 May 2010 07:42 Lie Ryan <lie.1296(a)gmail.com> writes: > On 05/11/10 09:56, Ben Bacarisse wrote: >> Seebs <usenet-nospam(a)seebs.net> writes: >> >>> On 2010-05-10, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> <snip> >>>> You can't assume that the data is contiguous or, to be a little more >>>> general, that a single [] operation means the same as three of them. >>>> This is, after all, C++ not C. >>> >>> In C++ it's at least conceivable that someone could come up with some >>> exceptionally sneaky overloading of [] to make it viable. >> >> That's why I said "you can't assume...". It is conceivable but it is >> not a sensible assumption for the poster[1] to make. The post was about >> a re-write to simplify come code. If that involves a "sneaky >> overloading of []" any argument about simplification is blown away. > > If it hides the complexity, then it could be argued that it's simpler, > at least from the outside. For the purposes of evaluating the complexity of a solution, you have to look at all the code. If a re-definition of is [] involved, then that is part of the solution and we never got to see it. I said that the argument is blown away -- not necessarily the conclusion. All code can be simplified to "find_solution_to_problem()" (or some variation thereof) but that's not a sound argument. > C/C++ hides the complexity of assembly, who > would argue that? > > I think there are two separate definition of complexity: Only two? :-) > - subjective complexity: how complex the source code looks like > - objective complexity: how complex what the machine is actually doing <snip> -- Ben.
From: Richard Heathfield on 12 May 2010 07:44
Nick Keighley wrote: > On 12 May, 03:00, pete <pfil...(a)mindspring.com> wrote: <snip> >> I find SEME to be less objectionable in functions >> which are small enough so that you can't look at one exit >> without noticing the all the rest of the exits. > > is there any other sort of function? Hell yes! -- 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 |