Freeing a sprite from memory

[olafurw]

I saw another post that stated that "You have nothing to do except properly managing the lifetime of your instances."

Since I'm new with SFML I'm wondering how I would go by doing this.

I have a vector of missiles.

Code: [Select]


struct missile
{
sf::Sprite Sprite;
float angle;
};

std::vector<missile> vMissiles;

vMissiles.push_back(Missile);


This all works fine and dandy, but what I'm worried about is when the missile exits the screen, I want to free it from memory. I'm seeing the executable grow in memory for each shot I do.

Currently I'm just not drawing them anymore, but what else can I do?

[OniLinkPlus]

You should use a vector of pointers to Missiles, then push_back(new missile Missile(constructorarguments));
When you exit the game, make a piece of code that iterates through the vector, deleting each Missile as you go, and then clear the vector at the end with vector.clear(). You can also create a function for this that you can run at any time to clear it out.

[dunce]

For entities with short life like missiles and bullets you can create a pool of constructed objects to avoid lots of time-consuming construction-destruction operations.

[Laurent]

Just remove your missile from the vector when it exits the screen. There's no need to dynamically allocate/free them, but maybe a std::list would be more relevant than a std::vector (less internal copies, faster removal, easy to iterate sequentially).

[Nexus]

You should use a vector of pointers to Missiles, then push_back(new missile Missile(constructorarguments));

Why that? Using raw pointers (that own their target) inside STL containers brings a lot of problems. Besides, you lose the advantage of std::vector to pre-allocate space and you have to manually allocate and deallocate every object, which is not only error-prone, but likely to be slower.

Please avoid dealing with raw, owning pointers in STL containers, where possible. Do not underestimate the risks. The most important ones of them are:

• Memory leaks, since you can easily forget to free instances.
• Undefined behaviour, when dealing with STL algorithms that modify the sequence. Look at std::remove(), for example. Some of the elements remain duplicated after the operation. You just can't free the objects you normally would because you run into danger to invalidate other pointers in the range.
• Undefined behaviour, when you copy a container or parts of it. Multiple pointers share the same target, how do you want to find out which one is responsible to deallocate? Choose between memory leaks or double deletes.
• Not really a risk, but you can't use normal iterator or random-access syntax as you require an additional dereferencing. Vec.DoSomething() doesn't work, Itr->DoSomething() neither.

Why should we turn back to C-style hacking when we've got much safer, more powerful C++ language features like encapsulation and RAII? What is the reason to use STL containers, which are intended to do the low-level work for us, if we still decide to manage memory ourselves?

[olafurw]

Thanks for the reply guys.

I've changed the code into a list (since it's erase it fast) and it's working great now, it only allocates memory to a certain max and then I have the list erasing the items that are outside the screen.

[panithadrum]

For entities with short life like missiles and bullets you can create a pool of constructed objects to avoid lots of time-consuming construction-destruction operations.

I'm interested in your way. Can you explain what do you mean with a pool?

[Nexus]

I'm interested in your way. Can you explain what do you mean with a pool?

Normally, construction and destruction isn't performance-critical. I think, the missile won't have too many attributes, probably just a few bytes. Constructing them before doesn't help because assignment is still required in order to setup a valid state, and that's rather more expensive than construction.

In most cases, memory allocation and deallocation needs far more time than constructor and destructor calls. So, what might help is a memory pool. But that pays only out if you have got really many and really small objects (new and delete aren't implemented badly). Note that besides, a really optimized memory pool isn't easy to program and must abandon flexibility to fit a specific circumstance.

You also have to know that a std::vector allocates mostly more space than really required. So, push_back() has amortized constant complexity, only in some rare cases a reallocation is performed. Destruction is similar: The container firstly destroys each element, and then performs one deallocation on the whole range. Hence, I guess this is the best solution for you. If you suddely got problems, you will still be able to think about it; though spending too much time on premature optimization is not worth it.

[dunce]

Yea. I was not precise saying about construction and destruction of objects. I meant just allocation and freeing memory in the heap while dynamically creating and destroying objects. Besides wasting time it couses fragmentation of the memory.

Can you explain what do you mean with a pool?

A pool is a storage of allocated and constructed objects that may be used repeatedly. There are lots of examples of implemenations of pools. Basically you allocate memory for objects when you initialize your pool depending on the maximum amount of objects and create two stl collections of pointers, first for objects currently in use and second for free objects. If you want an object to appear on the scene you get it from the list of free ones, initialize it with needed params /position, mass, etc./ and make its sprite visible. When it is time for the object to die instead of being freed from the heap it is returned to the pool i.e. to the collection of free objects and is erased from the collection of used objects, and so on. You can create a pool with needed constant capacity or manage its capasity dynamically.