C++: Vector of Pointers to Objects from another Vector -
i have 2 classes, similar this:
class { public: b* ptr1; } class b { public: std::vector<a*> list; }
in main implementation, i'm doing this:
int main() { // there lot more objects b objects, i.e. listofa.size() >>> listofb.size() std::vector<a> listofa; std::vector<b> listofb; while (//some loop) { listofb[jj].list.push_back( &(listofa[ii]) ); listofa[ii].ptr1 = &( listofb[jj] ); } } // int main end
basically this. lot of objects assigned 1 b object, , these objects stored in pointer vector pointers. additionally, each of these objects pointer b object belong to. context, i'm doing connected components algorithm run-length-encoding (for image segmentation), class line segments , class b final objects in image.
so, pointers of vector in class b point objects stored in regular vector. these objects should deleted when regular vector goes out of scope, right? i've read vector of pointer in class b requires writing manual destructor, shouldn't case here, think...
the reason why i'm asking is, of course, because code keeps crashing. i'm using asus xtion pro camera images , performing algorithm on every image. weird thing is, program crashes whenever shake camera bit harder. when camera stationary or moved little or slowly, nothing happens. also, when use different algorithm (also connected components, without run-length-encoding , doesn't use pointers), nothing crashes, no matter how shake camera. also, in debug mode (which ran slower release mode), nothing crashed either.
i tried making destructor pointer vector in class b, resulted in "block valid" error, guess deleted twice. tried replacing every pointer wih c++11 std::shared_ptr, produced irregular behaviour , code still crashed when shaked camera.
i want know if in terms of memory leaking , pointer handling, code shown above seems fine or if there mistakes in code lead crashes.
edit (solved): solution (see accepted answer) ensure vector 'listofb' doesn't resized during run-time, example using 'reserve()' reserve enough space it. after doing this, worked fine! apparently worked, because if vector 'listofb' gets resized (by push_back()), internal memory adresses of b instances in changed, causing pointers in instances (which point b instances) point wrong adresses - , resulting in trouble, lead crash.
about camera shaking, apparently, shaking camera resulted in blurry pictures lot of elements segment, increasing number of objects (i.e., resulting in higher size required listofb). so, mystery solved! lot! :-)
i think design broken. listofb grow (you push_backs) , re-allocate internal data array, invalidating addresses stored in ptrs of instances. usual algorithm grow data size factor of 2 may explain while if not data arrives. also, long memory of old data still in address space of program (especially if on same memory page, example because new data fits in well), program may not crash accessing , retrieve old data.
on more constructive note: solution work if know maximum elements in advance, may hard (think 4k camera next year ;-)). in case can, way, take simple static array anyway.
perhaps use std::map
store objects instead of simple vector listofa. each object need unique id of sort (static counter in in easiest case) use key map. bs store keys, not addresses of as.
Comments
Post a Comment