I'm making a game and the game works around a class I call Cyber_State. Every state of the game is a subclass of Cyber_State, for example the title screen you see when you start the game and the actual game.

Every state has a member that is a pointer to a Cyber_State. When a state is created this pointer points to itself, if you want to change states you build the next state and make next_state point to it. For example if you load a game from the main menu you make a new game(subclass of Cyber_State) based on a file and point next_state to it. The main loop then switches the state it works with at the end of the current iteration

Cyber_State.h

#include <Ogre.h>
#include <OIS/OIS.h>
#include <CEGUI/CEGUI.h>
#include <OgreCEGUIRenderer.h>

#include "Cyber_Util.h"
#include "ogreconsole.h"

class Cyber_State
{
	protected:
		Cyber_Kernel *kernel;
		Cyber_State *transition;
	public:
		Cyber_State(Cyber_Kernel *kernel);
		virtual bool frameStarted(const Ogre::FrameEvent& evt);
		virtual bool frameEnded(const Ogre::FrameEvent& evt);
		virtual bool keyPressed(const OIS::KeyEvent &arg);
		virtual bool keyReleased(const OIS::KeyEvent &arg);
		virtual bool mouseMoved(const OIS::MouseEvent &arg);
		virtual bool mousePressed(const OIS::MouseEvent &arg, OIS::MouseButtonID id);
		virtual bool mouseReleased(const OIS::MouseEvent &arg, OIS::MouseButtonID id);
		Cyber_State *next_state();
};

#endif

Cyber_State.cpp

#include "Cyber_State.h"

Cyber_State::Cyber_State(Cyber_Kernel *kernel){this->kernel = kernel; transition = this;}

bool Cyber_State::frameStarted(const Ogre::FrameEvent& evt){return true;}

bool Cyber_State::frameEnded(const Ogre::FrameEvent& evt){return true;}

bool Cyber_State::keyPressed(const OIS::KeyEvent &arg){return true;}

bool Cyber_State::keyReleased(const OIS::KeyEvent &arg){return true;}

bool Cyber_State::mouseMoved(const OIS::MouseEvent &arg){return true;}

bool Cyber_State::mousePressed(const OIS::MouseEvent &arg, OIS::MouseButtonID id){return true;}

bool Cyber_State::mouseReleased(const OIS::MouseEvent &arg, OIS::MouseButtonID id){return true;}

Cyber_State *Cyber_State::next_state(){return transition;}

For an example in my game I run this function at the end of each frame

bool Cyber_Listener::frameEnded(const Ogre::FrameEvent& evt)
{
	state->frameEnded(evt);
	state = state->next_state();
	if(state == NULL)
	{
		running = false;
	}
    return running;
}

My concern is this, what is the life span of a state returned by new_state? If I should delete the old state or it's memory gets freed automatically will the state returned by next_state be destroyed too? Or since Cyber_State only stores a pointer to to the next state will the next state itself be unharmed and accessible while I have a reference to it? While I'm at it does anyone have any links to help me understand memory in c++?

Recommended Answers

All 5 Replies

A pointer value will never been "deleted" automatically. The life span of the state pointer variable does not bear a relation to the life span of the referred object.

In other words, a pointer is a road sign only: "that's a road to Pompeii". May be, the Pompeii was strewn with Vesuvias volcano eruption ashes...

All about pointers for newcomers (and all others ;)):
http://eternallyconfuzzled.com/tuts/languages/jsw_tut_pointers.aspx

commented: wow nice explanation , I can use your words as it is to explain to to somebody +1

My concern is this, what is the life span of a state returned by new_state?

I'm a little confused by that but I assume you meant next_state and not "new state". I don't see you allocating any memory, just moving pointers around, so presumably you allocate the states dynamically somewhere (using new Cyber_State)? If that's the case, the life span of the state is until you delete it. If you delete a state object (A) which contains a pointer to another state object (B) then the pointer in A is freed but object B is still valid and you'd better make sure you still have a pointer to it otherwise it's inaccessible and you have a memory leak.
So remember that any memory you allocate with "new" must be freed with "delete" and you need to care of that. It won't happen automatically.

So remember that any memory you allocate with "new" must be freed with "delete" and you need to care of that. It won't happen automatically.

Unless you're using the <auto_ptr> template, in that case the reserved memory will automatically be freed when the pointer goes out of scope ...

That seems to answer my question well enough. I knew the rule that you free memory made with new with delete but I've seen a lot of examples where this isn't done. They were typically arrays of a few numbers so maybe they didn't care, or does delete basically get called on everything when a program closes?

That seems to answer my question well enough. I knew the rule that you free memory made with new with delete but I've seen a lot of examples where this isn't done. They were typically arrays of a few numbers so maybe they didn't care, or does delete basically get called on everything when a program closes?

It's true that the memory is returned to the OS after the application closes, so in that respect the loss of a small amount of memory during the application isn't going to cause a problem. However, you can see that leaving leaks is bad practice for a whole host of reasons. The class containing your leak maybe reused elsewhere in other apps in such a way that a large leak occurs. You may change the operation slightly which causes a single one-time leak to become a cumulative leak.
Basically, don't leave the OS to clean up for you, one day you'll write code which needs to work, and it'll bite you in the bum.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.