Skip to main content
gamedev.net
🔒 Locked

std::vector troubles

Started by Blabberboy [disabled] May 11, 2003 at 1:26 AM 18 replies 1.2k views
Original Post
Blabberboy [disabled]
Blabberboy [disabled]
Alright, first, here's the gist of what I'm doing: 
    
std::vector<CObject*> vObjs;

// Initialize 50 objects

for(int i=0; i<50; i++)
{
 vObjs.push_back(new CObject);
}

// Main loop part:

while(1)
{
 // do usual windows stuff

 // ...


 // loop through all objects

 for(int i=0; i<vObjs.size(); i++)
 {
  // Do stuff with vObjs[i]


  if (vObjs[i]->toDelete)
  {
   std::vector<CUnit*>::iterator it = &vObjs[i];
   delete vObjs[i];
   vObjs.erase(it);
  }
 }
}
now, for what's happening. let's say vObjs[0] is set to be deleted. it gets the the if() thing, and goes in, deletes the object. on the next time through the for() loop, in the "Do stuff with vObjs" section when i=0, my game crashes when it tries to access members from vObjs[0]. probly didn't really explain it super clearly, but hopefully someone can figure out what I'm saying. anyways, ya... I need some help with this. I'm guessing it has something to do with how I'm deleting objects, but I can't figure out what's wrong. EDIT: thought I'd mention that I have another vector<> similar to this one in my app too, running essentially the same, but it works when I delete from it... [edited by - BlabberBoy on May 11, 2003 2:29:09 AM]
Sneftel
Sneftel
Ah, the old vector erasure problem.

Here''s the solution.


  
vector<int> v;
vector<int>::iterator i = v.begin();

while(i != v.end())
{
    if(*i == 5)
    {
        i = v.erase(i);
    }
    else
    {
        ++i;
    }
}


How appropriate. You fight like a cow.
Blabberboy [disabled]
Blabberboy [disabled]
That''s a start. Except, since my vector is a bunch of pointers, shouldn''t I need a delete in there too? I tried it before and after the .erase() but both times it broke.
Hazelnuss
Hazelnuss
I had the same problem. Here is how i solved it(is there a better way??)


	list < IGarbageCollected * >::iterator iter;

	for(iter = m_Clients.begin(); iter != m_Clients.end(); )
	{
		if((*iter)->AGoodDayToDie)
		{
			IGarbageCollected * tmp = *iter;
			++iter;
			tmp->Kill(); // <- delete this;
		}
		else
		{
			++iter;
		}
	}


Oh and this is only a prototype... so please don't comment on the names of the variables, etc. I know how to do proper naming.

[edited by - Hazelnuss on May 11, 2003 4:03:12 AM]

[edited by - Hazelnuss on May 11, 2003 4:52:07 AM]
Oluseyi
Oluseyi
quote:
Original post by Hazelnuss
(is there a better way??)
Sure. Wrap your pointer in a shared/smart pointer object which deallocates in the destructor.
Hazelnuss
Hazelnuss
It''s slower... with better i meant better in terms of STL-usage.
Sneftel
Sneftel
quote:
Original post by BlabberBoy
That''s a start. Except, since my vector is a bunch of pointers, shouldn''t I need a delete in there too? I tried it before and after the .erase() but both times it broke.


Yeah, to adjust it for pointers, stick in a "delete *i" right before the v.erase(i).

How appropriate. You fight like a cow.
Hazelnuss
Hazelnuss
I tried that but it crashed the program!?
Sneftel
Sneftel
Then you need to make sure that your vector isn''t holding invalid pointers.

How appropriate. You fight like a cow.
Oluseyi
Oluseyi
quote:
Original post by Hazelnuss
It''s slower... with better i meant better in terms of STL-usage.
STL containers are generally written to expect POD types. Besides, are you sure it''s actually slower? Have you profiled it to verify? The only real problem with wrapping your pointer in a shared/smart pointer object is code bloat from template instantiation.
Blabberboy [disabled]
Blabberboy [disabled]
grrr... I''ve tried all the suggestions here... one of my vectors has worked all the time, but the other (exact same construct, etc) doesn''t...
Sneftel
Sneftel
That''s obviously because the pointers you''re deleting point to random or already-deleted memory. The erasing code is fine.

How appropriate. You fight like a cow.
Blabberboy [disabled]
Blabberboy [disabled]
the weird thing is it''s not actually the delete code that breaks... but it seems to be caused by it. After deleting an object from the list, it''s in a different part of code that deals with the vector that it breaks.
Sneftel
Sneftel
In that case, most likely you are overrunning a dynamically allocated array elsewhere, overwriting the information block for another allocation.

How appropriate. You fight like a cow.
Dire.Wolf
Dire.Wolf
Your code wouldn''t happen to be multithreaded, would it?

[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
SabreMan
SabreMan
quote:
Original post by BlabberBoy
the weird thing is it''s not actually the delete code that breaks... but it seems to be caused by it.

What requirements are placed on your classes in order for them to be containable by the standard containers? Do your classes conform to those requirements?
Sneftel
Sneftel
quote:
Original post by SabreMan
What requirements are placed on your classes in order for them to be containable by the standard containers? Do your classes conform to those requirements?
He''s storing pointers, which are POD types. No problem there.

How appropriate. You fight like a cow.
Sneftel
Sneftel
quote:
Original post by Anonymous Poster
Don''t use stl for node lists, write your own instead.

Nothing wrong with storing pointers in STL containers. If he profiles it later and the extra indirection is too slow, _then_ he can waste the extra time to write a container class.
quote:
btw, if a delete crashes the software it is always because the pointer is invalid.
You must not have been programming for very long. Allocator/deallocator failures are the least localized of bugs.

How appropriate. You fight like a cow.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.