Sign in to follow this  
darenking

How do you store a pointer to an object as a static thingy?

Recommended Posts

Hi! In my game I have a Maze object, and lots of instances of an Actor object. I want the Actor objects to be able to access the Maze object. At the moment I send the address of the Maze to the Actors every time I tell them to update: m_Actors[count]->Update(m_Maze); This works perfectly well, but I'm sure it would be more efficient to store the address of the Maze as a static member. I've tried it like this but it doesn't work:
//actor.h file
class Actor
{
private:
	static Maze& maze;
//etc


//actor.cpp file

Maze& Actor::maze; // <--------this is where the error is...

Actor::Actor(const Maze& maze)
{
//etc


I get this error: 'Actor::maze declared as a reference but not initialized'

Share this post


Link to post
Share on other sites
As the error says, if you declare a reference that isn't a function argument, you have to initialize it. You can try using a pointer instead of a reference.

Share this post


Link to post
Share on other sites
yes, references are special ... they are never SUPPOSED to not be valid at any point after they come into scope.

just like a function which accepts a reference should be able to count on it being valid and not null or garbage, your code that uses the static reference should be able to count on it being valid as well, therefore the rule is it must be initialized in the line in which it is declared ...

If every actor must belong to the same maze (as evidenced by the static declaration) ... you could use a singleton type pattern to retrieve that maze instead of storing a static ref / pointer in each class which uses mazes.

Share this post


Link to post
Share on other sites
So if I pass a pointer instead of a reference, will it be straightforward? I can just store the pointer as a static?

How do I do that?

Hmm.

Share this post


Link to post
Share on other sites
in actor.h
class actor{
public:
static maze* pMaze;
};

in actor.cpp
static maze* actor::pMaze;

set the ptr once and it will be the same in every actor object

Share this post


Link to post
Share on other sites
Quote:
Original post by darenking
This works perfectly well, but I'm sure it would be more efficient to store the address of the Maze as a static member.

I doubt you're bottlenecked here. Actually, I'd argue from a CPU's perspective, the static version hurts performance. Why? Static variables are typically not stored near function-local variables, which impairs locality (unless, of course, the variable is allocated a register).

However, this is just wild conjecture. The nonstatic version is easier to read, IMO, and that should be the concern here. :)

Share this post


Link to post
Share on other sites
It's unlikely to make any performance difference, but may as well keep things simple :) Another option would be to make the *maze itself* static, assuming there really is only the one of them. Then instead of accessing it via a static reference in the Actor class, access it directly through whatever namespace the Maze is put into. (But don't let this be an excuse for poor encapsulation! Give the Maze an appropriate interface, and use that.)

Share this post


Link to post
Share on other sites
As a general rule: don't try performance optimizations until you actually run into a performance problem. In this case you seem only to assume there is a problem. To me it seems you are creating an ugly solution to a (IMO) non-existent problem.

Tom

Share this post


Link to post
Share on other sites
So overall which is best?

I've currently just stored the pointer to the Maze object as a normal member variable, rather than a static variable:


class Actor
{
private:
//variables
Maze* m_pMaze;



Initializing it when I create the Actors:


//create actors
for ( int actor=0 ; actor<2 ; actor++ )
{
Actor* newActor = new Actor(&m_Maze);
m_Actors.push_back( newActor );
}



It seems the simplest way to do it, when you look at the actual code, though of course if there are 200 actors then there's going to be 200 pointers to the same Maze object, as I'm only likely to have one Maze in the whole game.

But then, maybe later on there will be more than one Maze, like if I do bonus rooms like in Super Mario, rooms that you can pop into and pop out of again.

So perhaps it's best I leave it like this, then I can have different Actors (monsters or whatever) in different mazes.


Share this post


Link to post
Share on other sites
The initial decision as to whether a thing should be static or not should NOT be based on performance or on style, but instead of correctly modeling your problem.

IE. Is each actor associated with 1 and only 1 maze? Is every actor associated with the same maze?

Only after you understand what the logical model of your problem is should you then add some consideration of style and performance.

Also, don't worry TOO much about the future either - questions like, "will I ever possibly want to create more than 1 maze at the same time" are much less usefull than question like "am I likely to want to have more than 1 maze at the same time, in the near future" ... because often you can refactor your code to support newer features almost as easily as you can figure out your long term goals ahead of time (once you have practice at keeping your code designs clean, and some experience with refactoring).

Also realize, that static variables are the improved version of global variables. They are better than old globals because they are scoped and located with the class which they should affect. But there is still the potential of using too many of them so that people can no longer see what's going on when you call a function, because they can't keep track of all of the implicit global / static variables being used behind the scenes. Of course passing extra parameters to every function call is often even worse. -- its all about style --

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this