Hi Everyone,

I have recently started writing an engine in C++ / SDL for a horizontal scrolling shooter, and most of the functionality that I wanted for it is done.
Now I am trying to deal with the memory leaks, and with that I would appreciate some help.

I store my particles, stars, bullets, enemies in my World object, that has vectors for them to be contained, such as these:



vector<Enemy> v_enemies;
vector<Enemy>::iterator v_enemies_it;
vector<Particle> v_particles;
vector<Particle>::iterator v_particles_it;


new objects to these vectors are added in several different functions in the following way:


Particle a(xx, yy, 6);
v_particles.push_back(a);


when the vectors are dead and flagged to be deleted, I erase them from the vector with remove-erase idiom in the following way:

v_particles.erase(remove_if(v_particles.begin(), v_particles.end(), dead_p), v_particles.end());


I do understand, that the memory leak is because the fact that the vector.erase only deletes the pointer to the object, and not the object itself, however when I tried to step through the vector with its iterator manually in a loop, I have encountered crashes due to the fact that the vector iterator is invalidated when the vector is reallocated.

I would really appreciate it if someone could provide me a method of erasing dead object from the vector, in a way that the object itself is deleted, not only its pointer. Also, I suspect my way of adding the object to the vector might not be the best way either (should I use "new"?).

I hope I have not broken any forum rules. This is my first post, so please go easy on me .
Thanks in advance!

(btw here is a short clip of the game engine so far: [media][/media])

You are putting copies of a particle object on the vector. This copy will be destructed within vector::erase(). If you have allocated pointers in the particle object itself, its up to you to delete them.

Thanks for the quick answer.
Are you saying that the vector itself contains the objects, and when erase is called not only a pointer gets deleted, but the object itself?

Below, I create particle a, and I create a copy of particle a with the vector.push_back()?

Particle a(xx, yy, 6);
v_particles.push_back(a);


If that is the case the memory leak is because the first Particle a(xx,yy,6); line, right?

Could you help me how I could make sure that the object is created only once, and the vector.erase will delete it anyway, or that I could delete the first object itself after its copy has been pushed back to the vector container?

EDIT:
I have modified all the code with vector.push_back like this:
Particle a(xx, yy, 6);
v_particles.push_back(a);
a.~Particle();


This way if the memory leak's cause would be that only the copy gets deleted and the originally created "a" keeps accumulating, however it still seems to be leaking memory, with the same rate as before..

Your vectors are not storing pointers. If they were storing pointers they would be declared something like this:

vector<particle*> v_pParticles; // store a pointer to a particle

whereas you are storing a particle object. When you call erase for your vector this will call the destructor for the particle and thus destroy your particle. If however, you have pointers to textures or other objects that are not released or destroyed then when your particle object is destroyed this will leave memory leaks.

The objects you are storing in the vectors is where you should be looking for your memory leaks (in your example the Particle class and the Enemy class to see if every new or new [] has a delete or delete[] and all pointers are not left dangling).

Actually, I do not see any way that one of the lines you posted could cause a memory leak (except when one of your classes allocates memory inside its contructor that is not freed in the destructor). Since you are not constructing objects on the heap using new, all objects cou create are created on the stack. Those will be deleted automatically when they go out of scope. The vector itself stores copies of your object:

Particle a(xx, yy, 6); // creates a new Particle object on the STACK
v_particles.push_back(a); // creates a new Particle object inside push_back and uses the copy constructor of Particle to do so.


In order to find memory leaks you should look into tools that do that for you, e.g. valgrind.

Thanks, so I am actually storing the objects.
All objects that are being created in enemy and the likes are added and erased the same way.
Neither new or delete are called anywhere in the code.

The only other thing that I could have thought of causing a memory leak are the SDL_Surface -es, however I load all the images and create surfaces only during initialization, all the created objects only use pointers to those surfaces.

Just to make sure, I freed for example the surface enemies used, but when the first enemy died, all the other enemies' surface disappeared as well, so it means the newly created objects don't create surfaces with them.

The memory leak is pretty big too, like 1MByte / 5 seconds...

Anyways, thanks for the help

EDIT: brx, thanks for the advice, I'll check out valgrind

EDIT:
I have modified all the code with vector.push_back like this:
Particle a(xx, yy, 6);
v_particles.push_back(a);
a.~Particle();


Do not call destructors explicitly except when you REALLY know what you are doing. Read this: http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.5

Thanks, I didn't know that.

Since a is recreated as a copy during vector.push_back(), only the one in the vector will get used, shown and eventually deleted.

What happens to the originally created "a" Particle? If it just stays there, and takes up memory, how am I supposed to get rid of it, without calling its destructor?
Since it wasn't created with "new", "delete" cannot be called either, right?

Thanks, I didn't know that.

Since a is recreated as a copy during vector.push_back(), only the one in the vector will get used, shown and eventually deleted.

What happens to the originally created "a" Particle? If it just stays there, and takes up memory, how am I supposed to get rid of it, without calling its destructor?
Since it wasn't created with "new", "delete" cannot be called either, right?

The object's lifetime is managed automatically. Sooner or later it will go out of scope, at which point its destructor is called and the storage is released.

Alright, thanks for all the responses, all of you were right, and the memory leak did not come from where I thought it did.
Since then I looked over all the code, disabling everything possible, and enabling them gradually, to see when the memory leak kicks in, and I have found the source of it.

Even though this isn't related to the thread title anymore, if it is not necessary I wouldn't start another for this, maybe some of you will spot the problem right away, I am not too experienced in c++, at least not in memory management, as I have never worked on anything big enough to make me worry about memory.

This is what causes the memory leak, this is a HUD function, to display the number of collected red orbs on top of the screen, using SDL_ttf.h
For me to be able to use that to output a number, I had to convert int to string :


void Hud::show_red_orb_counter()
{
red_orb_exact = w->myPlayer.p_orb_count();
if (red_orb_exact > red_orb_counter){
red_orb_counter++;
red_orb_counter_changing = true;
//if (frame % 2 == 0)

}
else
{
red_orb_counter_changing = false;
}
if (red_orb_counter_changing)
{
if (red_orb_counter_color.r < 245)
red_orb_counter_color.r = red_orb_counter_color.r + 10;
}
else
{
if (red_orb_counter_color.r > 115)
red_orb_counter_color.r--;
}
char buffer[33];
_itoa (red_orb_counter, buffer, 10);
red_orb_counter_surf = TTF_RenderText_Solid( font, buffer, red_orb_counter_color );
apply_surface( 295, 5, red_orb_counter_surf, screen );


}


I guess only the last four lines are relevant, probably the stuff with the conversion. I have found this int to const char solution somewhere, and copied it as it is, I am not really familiar with _itoa either.

Could someone tell me why this causes memory leak, and if this is a bad implementation for int to const char conversion, could you provide an alternate way?