• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
chondee

c++ : Deleting object (not just its pointer) from vector

13 posts in this topic

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:


[CODE]
vector<Enemy> v_enemies;
vector<Enemy>::iterator v_enemies_it;
vector<Particle> v_particles;
vector<Particle>::iterator v_particles_it;
[/CODE]

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

[CODE]
Particle a(xx, yy, 6);
v_particles.push_back(a);
[/CODE]

when the vectors are dead and flagged to be deleted, I erase them from the vector with remove-erase idiom in the following way:
[CODE]
v_particles.erase(remove_if(v_particles.begin(), v_particles.end(), dead_p), v_particles.end());
[/CODE]

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 [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img].
Thanks in advance!

(btw here is a short clip of the game engine so far: [media]http://www.youtube.com/watch?v=EjaTcaEIQSU[/media])
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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()?
[CODE]
Particle a(xx, yy, 6);
v_particles.push_back(a);
[/CODE]

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:[CODE]
Particle a(xx, yy, 6);
v_particles.push_back(a);
a.~Particle();
[/CODE]

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.. Edited by chondee
0

Share this post


Link to post
Share on other sites
Your vectors are not storing pointers. If they were storing pointers they would be declared something like this:

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

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).
1

Share this post


Link to post
Share on other sites
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:
[CODE]
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.
[/CODE]

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

Share this post


Link to post
Share on other sites
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 Edited by chondee
0

Share this post


Link to post
Share on other sites
[quote name='chondee' timestamp='1326443020' post='4902263']

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

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

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
[quote name='chondee' timestamp='1326446758' post='4902278']
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?
[/quote]
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.
1

Share this post


Link to post
Share on other sites
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 :

[CODE]
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 );


}
[/CODE]

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?
0

Share this post


Link to post
Share on other sites
I'm not sure, you might be right.
maybe it creates another surface every frame, I'll look into that now

EDIT:
Yeah, that was it :)

calling SDL_FreeSurface( red_orb_counter_surf ); afterwards solves it.

Thank you! Edited by chondee
0

Share this post


Link to post
Share on other sites
You always need to read the documentation to make sure you aren't causing memory leaks when using API functions. Functions with "create" in their name typically allocate memory, and functions with "get" sometimes increment reference counts. The documentation will tell you if you need to call the corresponding "free" or "release" functions.
1

Share this post


Link to post
Share on other sites
[quote name='taz0010' timestamp='1326507405' post='4902536']
You always need to read the documentation to make sure you aren't causing memory leaks when using API functions. Functions with "create" in their name typically allocate memory, and functions with "get" sometimes increment reference counts. The documentation will tell you if you need to call the corresponding "free" or "release" functions.
[/quote]

Yes, you are right, I ran into this whole thing a bit hastily, I was too excited :)
0

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  
Followers 0