Perhaps as a test, the address of the object must fall within the memory address reserved for the vector. Can the copy constructor drop an index value in the object, perhaps based on the distance between the new copy and the first vector element? The copy constructor will have to distinguish whether the copy is because of a vector being modified or if it is because of some other function in the program that requires a copy to be made. You have to copy the old object into a new memory address. I don't know if move constructor can work in this scenario because vector memory has to be contiguous. I am open to a more performant solution if there is one.Ĭan a copy or move constructor be utilized to achieve this? As a vector resizes, it uses a copy constructor to move things up and down I think. There is probably a significant performance impact with the vector resizing with inserts and deletes. I am also thinking that instead of a vector of SimRequest objects, I will just use a vector of Simrequest pointers. Each time I use the object, it automatically knows its associated buffer. If that is possible with very minimal performance impact, then I don't have to iterate over the vector to reassign the index pointer to double whenever I make a change to the vector. INSTEAD: expose the INDEX and that will be safe (or if not safe, you will KNOW that because you called pop back or clear or whatever that invalidated it or you can use. You must NOT expose the pointer to a vector's data to something that could HOLD ONTO it for use later, and multi-threaded programs it can go invalid almost as fast as you can pass it back if one of the threads is adding to the vector! Use caution with this if you use it at all. If you expose this, some user may keep the pointer you provided around and it could go invalid and cause a crash/bug/problem. This is fine for the internals deep inside the magic that you do not expose. Therefore, store the index solves the problem, and if you need the pointer, you can cook it on the fly and it is valid until the next resize (return &array and you get the current correct one, and you still kept the as what you store, you just *return* the pointer). The index is the same as it was (its still the 3) but the &array is different. That is if you have 0,1,2,3,4 in the array, and the struct points to &array (the 3) and you stuff 1000 more numbers on it so it reallocates, then: Std::cout second.getElement(2) second.getElement(4) << '\n' #include #include #include struct ArrayPointerĪrrayPointer(std::string aName, int aSize, double* ptr)ĭouble* getArray() ĪrrayPointer a1( "ONE", 3, arr1), a2( "TWO", 4, arr2), a3( "THREE", 5, arr3)
0 kommentar(er)
