• Advertisement
Sign in to follow this  

vector push_back() corrupting data?

This topic is 4407 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a piece of code where I instantiate a c_mesh object, then add it to my vector, scn_meshes...
try
{
  c_mesh add_mesh(scn_device,
    pass_file,
    pass_id);

  scn_meshes.push_back(add_mesh);
}
catch(...)
{
  throw;
}
There is an int property, msh_id that's set to pass_id when the constructor is called. Everything's fine right up to the point where the code returns from the push_back(). At that point the property msh_id is somehow corrupted. Instead of being set to pass_id, as it was when leaving push_back(), it's set to some seemingly random number. Everything else in the object is fine. No exceptions seem to be thrown, although I must admit that I don't know enough about vectors to know if it would or should be throwing an exception from push_back(). I know there isn't much information here, but any tips on where to look would be greatly appreciated. Here's the class definition...
class c_mesh
{
  private:
    LPDIRECT3DDEVICE9          msh_device;    
    string                     msh_file;
    int                        msh_id;
    DWORD                      msh_material_count;
    vector<D3DMATERIAL9>       msh_materials;
    LPD3DXMESH                 msh_mesh;
    vector<LPDIRECT3DTEXTURE9> msh_textures;
  protected:
  public:
                               c_mesh       (LPDIRECT3DDEVICE9 pass_device,
                                 string pass_file,
                                 int pass_id);
                               c_mesh       (const c_mesh& rhs);
                              ~c_mesh       (void);

           c_mesh&             operator=    (const c_mesh& rhs);

           void                msh_draw     (void);
    inline int                 msh_get_id   (void)
                               {
                                 return msh_id;
                               };
    inline c_mesh*             msh_get_mesh (void)
                               {
                                 return this;
                               };
};

Share this post


Link to post
Share on other sites
Advertisement
1° Are you referring to the contents of add_mesh, or to the contents of the mesh inside the vector?

2° Use a watchpoint to determine the exact code that modifies the value and find the culprit.

Share this post


Link to post
Share on other sites
Quickly looking at the code, my guess is that the problem is in either your copy constructor or overloaded assignment operator (=).

Remember that when you're adding an object to a vector you're not adding the object to the vector - you're creating a copy of the object and adding the copy to the vector. If there's an error in your copy constructor or assignment operator the copy could have garbage values.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
your copy constructor is defined as what?


It's defined as something that *doesn't* include msh_id. :) That was it exactly. I only recently got into the habit of using copy constructors and I still get caught when I change a class.

Thank you sincerely for your help. Hopefully I can start answering more questions that I ask.

Share this post


Link to post
Share on other sites
This was my copy constructor...

c_mesh::c_mesh(const c_mesh& rhs)
{
try
{
msh_device = rhs.msh_device;
msh_device->AddRef();
msh_file = rhs.msh_file;
msh_material_count = rhs.msh_material_count;
msh_materials = rhs.msh_materials;
msh_mesh = rhs.msh_mesh;
msh_mesh->AddRef();
msh_textures = rhs.msh_textures;
for(DWORD i = 0; i < msh_material_count; i++)
{
msh_textures->AddRef();
}
}
catch(...)
{
throw;
}
}

Share this post


Link to post
Share on other sites
Seperately, in general, the STL does no error checking. You can overwrite the end of a vector just the same as any dynamic array. It makes sense for it not to since most people would do the checks anyway. Few would actually code a loop to execute until a range error exception is thrown. So you end up with both the application and library performing the same checks.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement