Promit:
targetEntity never goes out of scope (base on my desing) and it's added back to the entity list when it's time comes. It's gets deleted before the game exites.
jpetrie:
Sorry for not exaplaining more but all entities are in a CEntityManager which is a Singleton. The targeEntity (I've named it m_tempEntity) is also a member in entity manager. I was just attempting a small trick to make Asteroid a bit intersting :P I was shocked when I learned that erase() doesn't just remove the entity (I should have figured that out, it's 'erase' after all :P)
And just a FYI, this was the only problem in the code. The game works fine now and I'm blasting asteroids like crazy :P
vector's erase(): I did not know
I would agree. Why don't you want to know what you're doing wrong? Is it because of your hubris:
I mean, certainly you couldn't be wrong twice. That would be impossible.
Quote:
And just a FYI, this was the only problem in the code.
I mean, certainly you couldn't be wrong twice. That would be impossible.
Quote:Original post by Farraj
all entities are in a CEntityManager which is a Singleton.
this was the only problem in the code.
:)
Quote:Original post by Farraj
Well, then I guess the answer is that there is no way to 'remove' a class instance without actully deleteing it.
I got a few good ideas from you guys, thanks.
Well, seeing that I only wanted to remove only 1 entity from the entity vector, I've taking this approch. I would replace the target entity with a 'dummy' entity then delete the dumy entity:
// the entity I want delete is in position i = 4
targetEntity = entityList.at(i);
entityList.at(i) = new CEntity("dummy");
entityList.erase(entityList.begin() + i);
I know it's not clean, but due to that I only need to remove one entity I guess this well do. No harm in hacking once and while :P
Thanks.
If you are able to do this, it means your vector stores pointers, which means your destructors were not being called in the first place.
Just some constructive criticism from me [smile]
If you can't figure out the root cause of this problem, they I suggest that you should definitely do more reading on how C++ handles objects, and how STL containers such as std::vector do so as well.
The root cause here has nothing to do with your code, it has everything to do with your current level of understanding, I know some of the other members have ripped into your code, but their intent is to help you learn, so dont take it the wrong way.
So let me try explain it for you:
The life cycle of an object stored in a vector is directly controlled by the vector. When storing a object in an STL container, if more than a distinct data object (e.g. a struct with only primitive data members) then a copy constructor and a assignment operator are needed.
If the vector is being used as a check list or queue, e.g. simple a place to make a list of objects which need to be actioned upon (such as rendered) then pointers to existing objects should suffice, reduce data copying (copy a word size pointer rather than an entirely new copy of the object) however there are many caveats which go with this method, to do with memory management and stale pointers (pointers pointing to free'ed memory), and ofcourse preventing memory leaks.
I would suggest reading Thinking in C++ 2nd Edition, its a free PDF download, well written and has chapters 4 and 5 which cover STL to a good depth
If you can't figure out the root cause of this problem, they I suggest that you should definitely do more reading on how C++ handles objects, and how STL containers such as std::vector do so as well.
The root cause here has nothing to do with your code, it has everything to do with your current level of understanding, I know some of the other members have ripped into your code, but their intent is to help you learn, so dont take it the wrong way.
So let me try explain it for you:
The life cycle of an object stored in a vector is directly controlled by the vector. When storing a object in an STL container, if more than a distinct data object (e.g. a struct with only primitive data members) then a copy constructor and a assignment operator are needed.
If the vector is being used as a check list or queue, e.g. simple a place to make a list of objects which need to be actioned upon (such as rendered) then pointers to existing objects should suffice, reduce data copying (copy a word size pointer rather than an entirely new copy of the object) however there are many caveats which go with this method, to do with memory management and stale pointers (pointers pointing to free'ed memory), and ofcourse preventing memory leaks.
I would suggest reading Thinking in C++ 2nd Edition, its a free PDF download, well written and has chapters 4 and 5 which cover STL to a good depth
In my humble IMHO, what you should do is maintain 2 lists of entities:
- A list of pointers to entities (std::vector<Entity*>) that holds all your entities in the game. When an entity is removed from this list, it's forever gone. Depending on your game, you could use it for collision detection.
- Another list of pointers to entities that holds all the renderable entities. This list is a subset of the previous list. The elements are displayed to the screen, so you can easily add/remove entities when their coordinates are/aren't in the screen.
- A list of pointers to entities (std::vector<Entity*>) that holds all your entities in the game. When an entity is removed from this list, it's forever gone. Depending on your game, you could use it for collision detection.
- Another list of pointers to entities that holds all the renderable entities. This list is a subset of the previous list. The elements are displayed to the screen, so you can easily add/remove entities when their coordinates are/aren't in the screen.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement