[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Collider and Mover code
From: |
David Philippi |
Subject: |
Re: Collider and Mover code |
Date: |
Fri, 17 Jan 2003 19:11:53 +0100 |
User-agent: |
KMail/1.4.1 |
On Friday 17 January 2003 03:24, Gervase Lam wrote:
> I was brought up with the one return only principle in functions. That's
> why there is only one return in the method. A break could have been used
> in the loop instead. But since there is a way to avoid this as well, I
> avoided it!
Ah yes, one of those... I didn't need to take more than a glance at the link
you provided - it's from a C group but Pingus is C++ which is a whole lot
more different then most people seem to know.
> One return CAN help if awkward clear up code is required. For example, if
> the routine has many new statements which IDEALLY should only have one
> delete statement. One return point can help in this case.
In C++ you'd declare pointers which are to be deleted later in the method as
auto_ptr<> and don't worry about them anymore. One return point doesn't
protect you against exceptions anyway. In C++ you can avoid most problems
with multiple return points by using classes which are responsible for
cleaning up in their destructor if they aren't told that everything went
well. This doesn't protect against unclear code from multiple returns but
unclear code may be achieved by so many ways...
Another often stated argument is that multiple return statements prevent
optimizations by the compiler - that's an old one. They make things more
complex but GCC 3.x does optimize them if all return the same variable (and
in case of bool there isn't much to optimize anyway).
In a method as short as this there's no chance for a second return to cloud
things up and no way that any additional possible optimization will win
against the cost of running through the loop multiple times doing needless
checks.
> Though one return is good, sometimes it can cause unclear code. For
> example if there is a series of if statements that checks for errors. On
> an error being found, the routine must not run the rest of the code (i.e.
> return immediately). Though a flag could be used, it makes things less
> straightforward.
There you see something which leads to "The One Rule of programming to rule
them all": THERE ARE NO DESIGN RULES! Every time you'll hear someone tell you
about a design rule - correct him/her aloud or in your mind: it's a design
GUIDELINE, never a rule. There's no design rule without (most likely
multiple) exceptions in the world of programming. Always use them as the
default way to do something but keep your mind alert to prevent beeing a
slave to rules. It's even worse if you're people talk about OO principles
those are most often fanatics.
I guess you know that goto is very bad? It's not. I've used it only once in my
code so far and everyone looking at the code told me that it's bad when they
saw the goto. Then I asked them to take a look at the whole method and tell
me how they would solve the problem. Everyone had to admit that there was no
bettersolution then using goto and that it didn't harm the code at all. It's
just a command that you shouldn't tell new programmers about since it's very
easy to misuse it, in the hands of an expert it's a valuable tool.
BTW I tend to get a bit aroused whenever I hear someone speak about design
"rules" unless the audience are new programmers who don't need to know about
the alternatives yet. When you wrote that you didn't even use break to cancel
the loop when it's finished, a battery of red lights in my head went on. ;-)
If you insist on following the one return rule, a break most definitly should
go in there. This will very likely generate the same output as the variant
using two returns and no bool after a good optimizer went over the code.
> With regards to the Mover and Collider directory structure. Keeping to
> the current directory convention, mover.hxx could be put in
> Games/Pingus/src with linear_mover.hxx being put into a new directory
> called Games/Pingus/src/movers.
Yes, that would be a way. What about putting linear mover in a namespace
Movers? Reminds me of putting the Particle classes in a namespace...
> In a similar way, upright_pingu_collider.cxx and
> upright_pingu_collider.hxx could be put into Games/Pingus/src/colliders.
Along with a namespace Colliders...
> In any case, I think pingu_collider needs to be changed to just collider.
> This is because the abstract class pingu_collider should apply to any
> object, not just Pingus.
What other objects do you think should collide with each other? Defining the
scope of the class is required to answer your next questions.
> But does this mean that collider should not have a getpixel() method?
> Does getpixel() apply to all other objects? Should the class hierarchy be
> collider<-pingu_collider<-upright_pingu_collider or
> collider<-upright_pingu_collider?
Bye David
- Collider and Mover code, Gervase Lam, 2003/01/12
- Re: Collider and Mover code, Gervase Lam, 2003/01/16
- Re: Collider and Mover code,
David Philippi <=
- Re: Collider and Mover code, Gervase Lam, 2003/01/20
- Re: Collider and Mover code, Gervase Lam, 2003/01/24
- Re: Collider and Mover code, Gervase Lam, 2003/01/25
- Re: Collider and Mover code, Gervase Lam, 2003/01/27
- Re: Collider and Mover code, Gervase Lam, 2003/01/28