However, that is not proof that the pointers remain valid after the point of deletion.
The pointer in the vector that points to the object on the heap remains valid, the pointer to the position in the vector that holds the pointer to the object on the heap does not. This is true even if you take the item on the end of the vector and stick it into the removal point and pop the last item off the vector. You can no longer iterate the vector using iterators b/c when it reaches the point of removal it will throw an exception related to incompatible iterator types. I'm working on a fix for this.
It is very likely that an incorrectly implemented copy assignment operator is the one that is causing yaya's objects' pointers to become null pointers.
I could see this causing memory leaks and dangling pointers but I cannot see how it would nullify or invalidate all pointers in a vector beyond the point of removal. Those objects are on the heap and the vector could care less about them. It only contains the pointers to them but so could a thousand other objects. The only way they can become invalid is if someone has called delete on them and failed to set the pointer to 0 - provided this is being checked prior to using the pointers. The only way this could be accomplished in this context is if the object is doing a delete this in it's destructor. That would definitely cause some problems.
Code:
struct TEXTUREINFO
{
TEXTUREINFO() : Tex( NULL ), Name( "DefaultTextureName" ), Filename( "DefaultTextureFilename" ) {};
TEXTUREINFO( IDirect3DTexture9* tTex, std::string tName, std::string tFilename ) : Tex( tTex ), Name( tName ), Filename( tFilename ) {};
TEXTUREINFO( const TEXTUREINFO& copy );
~TEXTUREINFO();
TEXTUREINFO& operator=( const TEXTUREINFO& other );
IDirect3DTexture9* Tex;
std::string Name;
std::string Filename;
};
If inside the destructor you are performing a SAFE_RELEASE(Tex) this will invalidate all the textures after the point of removal. What you need is this type of vector:
Code:
typedef std::vector<TEXTUREINFO *> TextureVector;
TextureVector m_textureVector;
The only time I store the actual objects in the vector or any container is if they do not use dynamic memory and/or COM objects.
IE:
Code:
...
struct TextInfo
{
DWORD color;
std::string text;
};
typedef std::vector<TextInfo> TextVector;
TextVector g_textVector;
...
But this still does not get around the fundamental problem with vector. You cannot assign texture IDs to other objects if the ID is the index in the vector. Removal from the texture vector can cause the IDs to change thus changing all the textures that objects are depending on.