3 replies to this topic

[Zerocyde]

I don't really know how to word this so I'll just draw it in psudo code...

[source lang="cpp"]class ROOMCLASS{ a texture a constructor that creates that texture with the directx device a destructor that releases the texture}class HOUSECLASS{ a vector of ROOMCLASS called "rooms"; constructor: { ROOMCLASS temp_room; rooms.push_back(temp_room); }// at this point I have checked and the texture in both temp_room and rooms[0] are both valid.} // at this point a ROOMCLASS destructor is called and releases that texture without issue.HOUSECLASS houses;function MAKE_A_NEW_HOUSE{ HOUSECLASS temp_house; // at this point the texture in temp_house.room[0] appears to be invalid. houses.push_back(temp_house);} // at this point a ROOMCLASS destructor is called and causes an error.[/source]

Is the problem that you can't use vector.push_back when a texture is involved?

Edited by Zerocyde, 16 October 2012 - 11:11 PM.

[Hodgman]

No, push_back does what it says on the tin, regardless of types.

It's impossible to tell what's actually going on without some real code, but I would guess it would be to do with you breaking the rule of three.
N.B. this is the sequence of constructors/destructors going on. Seeing you've not written a copy constructor, the compiler is writing one for you, which isn't incrementing the texture's reference count as it should.

{
  vector<Object> vec;
  {
    Object temp;//call temp.Object() -- constructor
    vec.push_back(temp);//call vec[0].Object(temp) -- copy constructor
  }//calls temp.~Object() -- destructor
};//calls vec[0].~Object() -- destructor

[Bill Door]

Your ROOMCLASS is not properly copyable.

A vector copies and owns each object as it is inserted into the vector. A new ROOMCLASS instance is created using the copy constructor and the old one is deleted.

vector requires copyable classes.

I expect that you wrote ROOMCLASS so that it properly destroys the texture when it is deleted. You need a system for copying the texture reference or creating a new texture reference in the new instance of ROOMCLASS.

shared_ptr is often referred to for this purpose. I consider shared_ptr a crutch. Each class should learn to manage it's own resources. In this case, perhaps a management class for textures that uses shared_ptr would be useful. I would avoid using shared_ptr as a requirement for using HOUSECLASS.

[SiCrane]

A vector copies and owns each object as it is inserted into the vector. A new ROOMCLASS instance is created using the copy constructor and the old one is deleted.

vector requires copyable classes.

This changes with a C++11 compiler. Objects placed in a vector in C++11 only need to be movable, not necessarily copyable. Either way copy/move semantics need to be implemented properly, but what is necessary changes depending on the semantics you plan to support.