[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: |
Sun, 26 Jan 2003 10:32:56 +0100 |
User-agent: |
KMail/1.4.1 |
On Saturday 25 January 2003 20:27, Gervase Lam wrote:
> > - templates parameters should be named by using typename instead of
> I've changed it from Collider to ColliderFunctor.
Nice touch but I meant something different :-)
template<class Functor> --> template<typename Functor>
was what I had in mind. I hate the usage of class most in expressions like
template<template <class> foo>
Using typenam here makes things much easier to read in my opinion.
> I've made the change. However, it would be "interesting" if pingu_height
> were to change to a double in the far future, for example. But I think
> the likelihood of that happening is practically zero.
As long as we keep using window systems using pixels I don't think this will
happen. Although, just yesterday I've read about a project which tries to
replace X with a completely new system based on vector graphics instead of
pixels as the default... ;-)
> "Passing function objects by value instead of by reference has the
> advantage that you can pass constant and temporary expressions."
Note that they are saying by reference. You may very well pass constant or
temporary objects as const &.
> STL book. This needs to be done using references so that seq keeps its
> value.
Notice that they are here using a non-const reference so you can't use const
values or temporaries anymore.
> In this case, mover is taking in falling_down_pingu and falling_up_pingu
> by reference. This means that in the future, (non-const) colliders could
> receive feedback information.
Mover will never take any value by reference unless you change the signature
to Collider & collider. If you want to allow changeable colliders as well as
temporaries you'll need to methods:
virtual void update(const Vector& move, const Collider& collider) const =0
virtual void update(const Vector& move, Collider& collder) [ =0 ]
I guess that the non-const variant is less likely so it could be usefull to
provide an default implementation which consists of an assert(false).
> Letting the person using linear_mover decide what the type of the
> parameter is going to be provides more flexibility. The person is not
> forced make a value be passable by reference. If required, the person can
> use a temporary.
That's what I suggested, but this can only be achieved by providing two
methods.
> I think people can see this more easily. It is also flexible in that the
> person can ask for the Function Object to be passed by reference if
> needed, or not. The person has a choice.
Why do you think the person should ask for the object to be passed by
reference? It's declared as by value so it will never be something else.
> I've changed the counter i to an int. I assume that the expression (i <
> move_length) would promote i to a float before doing the comparison.
Well, you're partially right. It would be promoted to an float for the
comparison so using float is better but I think changing move_length to int
does even more good. We are operating with integer steps and so we're going
to loose the precision of float anyway - why not right at the beginning?
> I'll wait for the answers before posting the updates for this. I also
> need to sort out a strange compilation problem.
Are those compiler errors or linker errors? They look more like linker errors,
so you should make sure that the .o of upright_pingu_collider comes before
bomber.o in the linking stage (or rather the colliders.a must be before the
actions.a).
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, 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,
David Philippi <=
- Re: Collider and Mover code, Gervase Lam, 2003/01/27
- Re: Collider and Mover code, Gervase Lam, 2003/01/28