Hi, is it possible to cross convert a reverse_iterator with a normal iterator? e.g. ForwardIter = MyMap.rbegin().base(); (Not sure if it is syntatically correct) If it is possible to cross convert, how will the ++ / -- operator work on the converted iterators? Another question I have is, if i have a number of objects to be rendered each frame where object can be added or remove, should I: Method1 std::vector<OBJECT> ObjectList; std::vector<int> FreeObjectListID; - Hence if i remove a object from the list, i store the free location ID at the FreeObjectListID. - And when I add a object, I check for any free location ID and overwrite it. If not existing free ID is avaliable, then i just use ObjectList.push_back(); - And to render in each frame, i just iterate through the vector ObjectList and render them. Method2 std::map<int, OBJECT> ObjectList; - I would add and remove objects normally using the std::map, insert, [] and erase functions - To render in each frame, I would iterate through the map ObjectList and render them. Which method is a better suggestion, or are there better ways to implemnt it? Thanks

But Objects can be remove and inserted from the list. If I am to use std::list, won't the indexing of the object change?

Or is there a way i can erase an OBJECT from the std::list without knowing where it is stored in the list?

Quote:Original post by littlekid
But Objects can be remove and inserted from the list. If I am to use std::list, won't the indexing of the object change?

Yes (likewise with vectors). Keep in mind though that list elements don't really have 'indices', per se, as lists are not random access (you can use, say, std::advance() to find the object corresponding to a given 'index', but if you really want indexed access it's generally better just to use a vector).

Quote:Or is there a way i can erase an OBJECT from the std::list without knowing where it is stored in the list?

Depending on the nature of your objects, you might be able to use list::remove().

There are actually a number of ways you can go about removing expired objects. Here is one way to go about it:

    m_entities.erase(        std::remove_if(            m_entities.begin(),            m_entities.end(),            boost::bind(&Entity::Update, _1, elapsedMS)        ),        m_entities.end()    );

Basically, this updates all of the entities, and then removes those that are 'dead'. (Each entity is responsible for returning a value of 'true' from its update function when it's time for it be removed from the simulation.)

You shouldn't use std::remove_if() on std::lists. Instead you should use std::list::remove_if(); it's a lot more efficient.

I'm afraid you'd have to ask someone on the standards committee that one. I can give you guesses, but that's about it.

Quote:Original post by SiCrane
You shouldn't use std::remove_if() on std::lists. Instead you should use std::list::remove_if(); it's a lot more efficient.

For what it's worth, in my posted example (copied from my current project), m_entities is of type std::vector<boost::shared_ptr<Entity> >.

Sorry, I should have clarified that in my post.

Quote:Original post by rip-off
I was just wondering was there some odd technical reason. God knows there are enough of them in C++.

Well, if I had to guess it would because it's because doing so would require a list iterator be able to delete itself from the container without having a reference to the iterator's container. This is certainly technically possible, but not necessarily something they wanted as part of the mandated public interface for the list iterator, since actual iterator implementations are not something that the standards committee wanted to dictate.