Is this an ideal use for passing functions as an arguement...

I decided to scratch the old particle class I wrote for a new better one, the primary goal this time is I want one method to handle the "movement processing" based on certain values which a formula will manipulate.

Code:

---

void MovementInACircle (double a, double b, double c ) // etc...
void MovementInASquare (double a, double b, double c ) // etc...

---

Let's assume I define the classes method as such:

Code:

---

class ParticleManage
{
// ...
public:
        void Process((*proc)(double, double, double));
// ...

---

During development I'd like to swap out different "movement patterns" to work on them individually... so I might have...

Code:

---

ObjInst->Process((*MovementInACirle)(1.33, 2.342, 1.23));

---

I'd like to achieve this effect exactly, this might not be the ideal method and maybe there's a better way.

I want all movement algorithms as a separate component to the particle manager.
Am I on the right track?

I'd go with virtual methods and then override methods, but that doesn't give me a 'dynamic' approach. I might later have controls to swap out which "movement algorithm" will be used at any given time...

I'm just not 100% sure of my approach on this, I've never used functions as arguments so before I went in to it I thought i'd get some feedback. :-)

Not sure, if this is any better, but you might also try with function objects.

Code:

---

#include <iostream>

struct BaseMovement
{
    virtual ~BaseMovement() {};
    virtual void operator() ()const = 0;
};

struct CircleMovement: public BaseMovement
{
    virtual void operator() ()const
    {
        std::cout << "In circle... \n";
    }
};

struct SquareMovement: public BaseMovement
{
    virtual void operator() ()const
    {
        std::cout << "In square... \n";
    }
};

void foo(const BaseMovement& m)
{
    m();
}

int main()
{
    foo(SquareMovement());
    foo(CircleMovement());
}

---

I think it is rather important to make your environment an object as well.

It's infinitely simpler to let the environment throw particles around and trace their flight rather than having particles control their own movement. Partly because that never happens in real life, but maybe more importantly that you don't have to find a way to embed lots of algorithms inside of a particle class that may never be used.

I mean if your environment is something like a square then

Code:

---

square s;
particle elems[MANY];
coord here = { 2, 4 };
rate r = 2;

s.init( elems, MANY );
// Maybe put all these particles in the middle to start.

s.tosstoward( elems[1], here, r );

particle p;
s.inject( p, here, r );
// Let square figure out what  happens to all the other particles
// when a new particle comes inside at some rate of speed.

---

If I'm completely crazy let me know but that seems like a simpler model. Just figure out how you're going to allow particles to move in some environment. Then graph them if you want some output.

Function pointers are definitely the way to do dynamic function calls in C, but I seriously wonder if you'd not be better off doing this in a more OO way with C++. I know you said you considered it, but I still think you could manage it better than just throwing functions into the equation.

Quote:

---

Originally Posted by simpleid

I decided to scratch the old particle class I wrote for a new better one, the primary goal this time is I want one method to handle the "movement processing" based on certain values which a formula will manipulate.

---

A better method is to derive various movement functions from a common movement base class, e.g.:

Code:

---

class MovementMethod
{
public:
    virtual ~MovementMethod();

    virtual void move(double a, double b, double c);
};

class CircleMovement : public MovementMethod
{
public:
    // Circle-specific movement
    void move(double a, double b, double c);
};

class SquareMovement : public MovementMethod
{
public:
    // Square-specific movement
    void move(double a, double b, double c);
};

// etc...

---

You can still swap out the "movement algorithm" by associating a specific MovementMethod pointer with each object. You can change this pointer to point to a new movement algorithm at will.

huh.... well damn, i never considered making the environment an object before, thanks for that insight citizen, i can't believe i never considered it that way before, i think i'm definitely going to do that, and it will solve a lot of problems i had in a previous attempt... damn... that really is a good idea, lol...

yea, i think i'm going to do the movements via a base class, this is good. I like it... i was hoping to avoid function pointers just because they don't look very good in code hah...

:-) thanks, this has helped.

>> ObjInst->Process((*MovementInACirle)(1.33, 2.342, 1.23));

this is just invoking the callback function directly. the Process function should take the address of callback function, and the three doubles as arguments (unless they're generated internally, of course). if 'Process' is non-virtual, you can simply template it so that it can take both functions and objects as arguments.

Code:

---

class ParticleManage
{
 public:
 
 template <typename Function>
 void
 Process(Function callback, double a, double b, double c)
 {
            // do stuff
            callback(a, b, c);
 }
};
 
void
MovementInACircle(double a, double b, double c)
{
        cout << "MovementInACircle(" << a << "," << b << "," << c << ")" << endl;
}
 
struct MovementInASquare
{
    void
    operator () (double a, double b, double c) const
    {
            cout << "MovementInASquare(" << a << "," << b << "," << c << ")" << endl;
    }
};
 
int
main()
{
    ParticleManage pm;
    pm.Process(MovementInACircle, 0.0, 1.0, 2.0);
    pm.Process(MovementInASquare(), 3.0, 4.0, 5.0);
}

---

if you plan to 'store' the callback you might either stick with functions or else use some sort of functor object (boost::function would do, I believe).

What I may end up doing is designing the application to support 'plug-ins' (via assemblies) so I can build my software as a framework with most algorithms as a separate component. I prefer your approach sebatian, it seems very logical and correct.

Is there a way to achieve that effect though where all constants and variables are options within the "environment" separate from the functions which control the movement? Can these functions be designed to know ahead of time what variables will exist once called for an execute correctly? More importantly, what is the preferred method for achieving this effect?

Maybe none of my functions will require input, and I'll make all calculations based on "environment" settings. The application will be the host for the environment, and the algorithms for movement will be stored in assemblies.

I'm extremely fond of this idea, any information regarding this approach would be greatly appreciated. I'm going to spend some time searching around the net, but I'll keep an eye here for replies.