Alternative to Transport Variables

[jimmy]

Hi,

I have a main loop like this:

while (true) {
receive();
update();
draw();
}

Each stage (i.e. receive, update, draw) uses info from the previous
stage. I am currently passing this info with "transport variables".
These variables are set in one stage, and in the next, read and
cleared.

I find this very cumbersome and prone to errors (especially if I forget
to clear a variable). Is there some sort of design pattern or idiom
that could help?

Note: Each stage is infact traversing a tree so someLeaf.draw() would
not be called immediately after someLeaf.update().

-Jimmy

 

[msalters]

jimmy schreef:

Hi,

I have a main loop like this:

while (true) {
receive();
update();
draw();
}

Each stage (i.e. receive, update, draw) uses info from the previous
stage. I am currently passing this info with "transport variables".
These variables are set in one stage, and in the next, read and
cleared.

I find this very cumbersome and prone to errors (especially if I forget
to clear a variable). Is there some sort of design pattern or idiom
that could help?

What's wrong with objects?

Assuming your transport var hass class C,
why not write
C receive();
C update( C c ); // returns c;
void draw( C c );

C::~C will of course clear the variable. If copying C is too expensive,
you can implement C as a C_impl* and a share count.

HTH,
Michiel Salters

 

[Kristo]

jimmy schreef:

What's wrong with objects?

Assuming your transport var hass class C,
why not write
C receive();
C update( C c ); // returns c;
void draw( C c );

C::~C will of course clear the variable. If copying C is too expensive,
you can implement C as a C_impl* and a share count.

Why copy at all then? I suggest passing by reference instead. The
declarations for the functions might look like this:

C receive();
void update(C &c);
void draw(C &c);

And the resulting code would be:

while (true)
{
C c = receive();
update(c);
draw(c);
}

The variable c goes out of scope at the end of the loop body and its
destructor can clean up whatever it needs to. Also, if copying a C
object is expensive, try to facilitate the return-by-value optimization
in the receive function. See FAQ 10.9 for details if you don't know
what that is.

Kristo