   Why does this Object wonk out & get deleted ?
  Stepping through the debugger, the BBox object is okay at the entry of the function, but as soon as it enters the function, the vfptr object points to 0xccccc. I don't get it. 1. What is causing this ? 2. Why is there a virtual table reference in there when the object is not derived from other class. (Though, it resides in GameObject from which my Player class inherits and I retrieve the BBox from within player. But, why does the BBox have the reference ? Shouldn't it be player who should be maintained in that reference ?)For 1; some code for reference:A. I retrieve the bounding box from player. This returns a bounding box as expected. I then send its address to GetGridCells.const BoundingBox& l_Bbox = l_pPlayer->GetBoundingBox();boost::unordered_set < Cell*, CellPHash >& l_GridCells = GetGridCells ( &l_Bbox );B. This is where a_pBoundingBox goes crazy and gets that garbage value.boost::unordered_set< Cell*, CellPHash > CollisionMgr::GetGridCells(const BoundingBox *a_pBoundingBox){Can anyone please give me some idea as to why this is happening? Also, if you want me to post more code, please do let me know.Thanks!Edit:I think the following code is also pertinent, so I'm sticking this in here anyways:const BoundingBox& Player::GetBoundingBox(void){return BoundingBox( &GetBoundingSphere() );}const BoundingSphere& Player::GetBoundingSphere(void){BoundingSphere& l_BSphere = m_pGeomMesh->m_BoundingSphere;l_BSphere.m_Center = GetPosition();return l_BSphere;}// BoundingBox ConstructorBoundingBox(const BoundingSphere* a_pBoundingSphere);
  Shouldn't the GetGridCells function be returning a reference to a type of 'boost::unordered_set< Cell*, CellPHash >' instead of a copy ? I cannot tell this from your code, but there is obviously a mismatch between type and reference of type.   ;const BoundingBox& Player::GetBoundingBox(void)That returns a const refrence to a temporary objectconst BoundingBox& l_Bbox = l_pPlayer->GetBoundingBox();this stores a refrence to said temporary that is on the stack.GetGridCells ( &l_Bbox );being a function call, pushes a bunch of stuff onto the stack, destroying your temporary returned from GetBoundingBox. Thus, l_bBox is no longer pointing at anything valid.The root problem is that you return a reference to a temporary object in GetBoundingBox. You should never return a refrence to a temporary object (compiler should warn you about that).  Change the signature of the GetBoundingBox function, and make l_Bbox not a reference, and the problem should go away.;  @plastique: GetGridCells returns a copy since it creates a local boost::unordered_set within the function. So, when I invoke the function, I think I should copy the returned boost::unordered_set from GetGridCells rather than storing a reference to it. (This always confuses me...in fact, as I write this, I got confused! Shouldn't it be okay to just store the reference that is returned from GetGridCells since that would prevent the copy constructor of the unordered_set to be invoked!)So,I.boost::unordered_set < Cell*, CellPHash > l_GridCells = GetGridCells ( &l_Bbox );ORII.boost::unordered_set < Cell*, CellPHash >& l_GridCells = GetGridCells ( &l_Bbox );for signatureboost::unordered_set< Cell*, CellPHash > CollisionMgr::GetGridCells(const BoundingBox *a_pBoundingBox){boost::unordered_set < Cell*, CellPHash > l_CellSet;// ...return l_CellSet;}IMO, (II) should be the correct way of doing it, in order to avoid invoking the copy constructor. Eitherways, none of these helped in solving why BoundingBox is going out of scope when control hits GetGridCells(...) :-(   ;Quote:Original post by KulSeranconst BoundingBox& Player::GetBoundingBox(void)That returns a const refrence to a temporary objectconst BoundingBox& l_Bbox = l_pPlayer->GetBoundingBox();this stores a refrence to said temporary that is on the stack.GetGridCells ( &l_Bbox );being a function call, pushes a bunch of stuff onto the stack, destroying your temporary returned from GetBoundingBox. Thus, l_bBox is no longer pointing at anything valid.The root problem is that you return a reference to a temporary object in GetBoundingBox. You should never return a refrence to a temporary object (compiler should warn you about that).  Change the signature of the GetBoundingBox function, and make l_Bbox not a reference, and the problem should go away.One more thing, both:const BoundingBox& l_Bbox = l_pPlayer->GetBoundingBox();// ANDGetGridCells ( &l_Bbox );are invoked from within the same function (Update()). So, the way I understand it is..l_pPlayer->GetBoundingBox();creates a temporary object and l_Bbox stores a reference to it. This(object referenced by l_Bbox) is stored on the stack and stays on it as long as the function is on the stack i.e. Update. Now GetGridCells(&l_Bbox) is called from within Update(), so l_Bbox should still be valid ? (Or is it the case, that when GetGridCells is pushed onto the stack, l_Bbox goes out of scope ??? );  I was replying while the second part of the code wasn't there yet. The problem is that you can't return references for local objects inside a function body, as they get out of scope as soon as the function returns and leave an invalid reference.So either you can solve this by always copying those objects or for example by changing the function signatures to take references of those types which are supposed to be retreived, e.g.bool CollisionMgr::GetGridCells(boost::unordered_set< Cell*, CellPHash>& cellsReturned){  // fill the cellsReturned object  return true;};Quote:creates a temporary object and l_Bbox stores a reference to it. This(object referenced by l_Bbox) is stored on the stack and stays on it as long as the function is on the stack i.e. Update. Now GetGridCells(&l_Bbox) is called from within Update(), so l_Bbox should still be valid ? (Or is it the case, that when GetGridCells is pushed onto the stack, l_Bbox goes out of scope ??? )Nope. The issue is that l_Bbox goes out of scope the second GetBoundingBox returns. You get just enough life out of it to assign it to a NON-reference object. It's scope isn't inside Update() like you thought.;  Ah, I think I understand what you said. I have one more thing to ask...please bear with me..If I make the following changes:const BoundingBox Player::GetBoundingBox(void) { BoundingBox temp = BoundingBox();  return temp;}// This results in the following:- copy constructor on the object returned (temp) (&this new object due to CC gets assigned to whomsoever invoked it)- since temp object now goes out of scope, the destructor is called for local variable temp- Thus, in the end you do get one Bbox object that lives and stored with invokeeCorrect ?;Quote:const BoundingBox Player::GetBoundingBox(void) { BoundingBox temp = BoundingBox();  return temp;}BoundingBox bbox = Player->GetBoundingBox();that (un optimized) wouldcreate a temporary bounding box "t".copy-construct temp.destructor the temporary "t".return temp on the stack.bbox would be copy constructed from temp off the stack.temp would be destructed.Quite technically:const BoundingBox & Player::GetBoundingBox(void) { return BoundingBox(); }BoundingBox bbox = Player->GetBoundingBox();would create a temp boundingbox "t"copy construct bbox.call the destructor of boundingbox "t".your const reference does have SOME life to it. But as you saw above, it is very short, and easy to screw up.const BoundingBox Player::GetBoundingBox(void) { BoundingBox temp; return temp;}BoundingBox bbox = Player->GetBoundingBox();would create a temp boundingbox "temp"put it on the stack.copy construct bbox.call the destructor of boundingbox "temp".You'd save a little by not creating temp with the copy construct from temporary.But, there is a lot that the compiler might be able to optimize away, depending on how complex the constructors are.  So there is a good chance it could remove some of the extranious copying of data around.;  Yes, I do understand it now :-)Thanks a lot for your time and help! It has really helped me clear this age-old doubt.As a good practise, do you recommend returning by copying or by sending a reference of the variable in function-argument (esp given the case that I have here) ?   