I'm creating objects at runtime with vector.push_back() and i want to store the player object so i can use it whenever i want. So i store the pointer of the just created player to a global pointer variable, but when i push back the next object, the memory adress of the player changes, i think because the vector has to resize and therefore changes all of its elements locations.
for (int y = 0; y < 5; y++)
{
for (int x = 0; x < 10; x++)
{
switch (map[x + 10 * y])
{
case '1':
gameObjects.push_back(player);
playerPointer = &gameObjects.back();
break;
case '2':
gameObjects.push_back(block);
gameObjects.back().transform.pos = vec((float)x * 100, (float)y * 150, 0);
break;
}
}
}
but when i use
gameObjects.reserve(10000);
the location doesnt change, because its reserved and doesnt need to resize until the size becomes 10000 in this case.
So whats the catch? can you just reserve(1000000000) with no consequences? my RAM usage doesnt skyrocket.
Thanks in advance
The drawback of reserve( a lot ) is that you can either reserve far too much, which is a waste of memory, or too little, then reallocations will still happen.
Pointers to elements get invalidated when iterators get invalidated. For when iterators get invalidated I refer you to this question: Iterator invalidation rules.
Face it: std::vectors iterators are rather unstable (and thus also pointers to elements). You have several options:
Reserving enough space upfront can be a solution, though it isn't safe. Once you push more than you reserved, iterators are off.
When you are fine with reserving enough space for the maximum number of elements you can as well use a std::array.
Use indices. Assuming you do not reorder the vector and you never remove elements, indices are stable.
Use a std::list. Iterators of lists are much more stable than iterators into vectors. In particular, inserting to a list does not invalidate iterators. Though, consider the drawbacks of std::list compared to std::vector.
Store the elements elsewhere. Instead of storing the player in the vector you can store a (smart-) pointer to it in the vector. Reordering or reallocating the vector will then not affect pointers to the actual objects.
quickly after i posted this i realized that using pointers as an ID is stupid (especially with vectors) so i just gave the gameobject a const char* name and made a function which loops trough my gameobjects till it finds one with the name you seek and returns it. The i set a GameObject* to the gameobject* the function returns and from there i can use player->doStuff
Related
I wanted to ask you about the vector::shrink_to_fit() function.
Lets say i've got a vector of pointers to objects (or unique_ptr in my case)
and i want to resize it to the amount of objects that it stores.
At some point i remove some of the objects from the vector by choice using the release() function of unique_ptr
so there is a null pointer in that specific place in the vector as far as i know.
So i want to resize it and remove that null pointer in between the elements of the vector and i'm asking if i could do that with shrink_to_fit() function?
No, shrink_to_fit does not change the contents or size of the vector. All it might do is release some of its internal memory back to a lower level library or the OS, etc. behind the scenes. It may invalidate iterators, pointers, and references, but the only other change you might see would be a reduction of capacity(). It's also valid for shrink_to_fit to do absolutely nothing at all.
It sounds like you want the "Erase-remove" idiom:
vec.erase(std::remove(vec.begin(), vec.end(), nullptr), vec.end());
The std::remove shifts all the elements which don't compare equal to nullptr left, filling the "gaps". But it doesn't change the vector's size; instead it returns an iterator to the position in the vector just after the sequence of shifted elements; the rest of the elements still exist but have been moved from. Then the erase member function gets rid of those unnecessary end elements, reducing the vector's size.
Or as #chris notes, C++20 adds an erase overload to std::vector and a related erase_if, which makes things easier. They may already be supported in MSVC 2019. Using the new erase could just look like:
vec.erase(nullptr);
This quick test show that u can't do like this.
int x = 1;
vector<int*> a;
cout << a.capacity() << endl;
for (int i = 0; i < 10; ++i) {
a.push_back(&x);
}
cout << a.capacity() << endl;
a[9] = nullptr;
a.shrink_to_fit();
cout << a.capacity() << endl;
Result:
0
16
10
m_gates[index].release(); m_gates.shrink_to_fit();
Based on your comment, what you're looking for is simply to erase this single element from your vector right then and there. Replace both of these statements with:
m_gates.erase(m_gates.begin() + index);
Or a more generic version if swapping containers in the future is a possibility:
using std::begin;
m_gates.erase(std::next(begin(m_gates), index));
erase supports iterators rather than indices, so there's a conversion in there. This will remove the pointer from the vector while calling its destructor, which causes unique_ptr to properly clean up its memory.
Now erasing elements one by one could potentially be a performance concern. If it does end up being a concern, you can do what you were getting at in the question and null them out, then remove them all in one go later on:
m_gates[index].reset();
// At some point in the program's future:
std::erase(m_gates, nullptr);
What you have right now is highly likely to be a memory leak. release releases ownership of the managed memory, meaning you're now responsible for cleaning it up, which isn't what you were looking for. Both erase and reset (or equivalently, = {} or = nullptr) will actually call the destructor of unique_ptr while it still has ownership and properly clean up the memory. shrink_to_fit is for vector capacity, not size, and is unrelated.
at the end the solution that i found was simple:
void Controller::delete_allocated_memory(int index)
{
m_vec.erase(m_vec.begin() + index);
m_vec.shrink_to_fit();
}
it works fine even if the vector is made of unique_ptrs, as far as i know it doesn't even create the null pointer that i was talking about and it shifts left all existing objects in the vector.
what do you think?
I am making a game engine and need to use the std::vector container for all of the components and entities in the game.
In a script the user might need to hold a pointer to an entity or component, perhaps to continuously check some kind of state. If something is added to the vector that the pointer points to and the capacity is exceeded, it is my understanding that the vector will allocate new memory and every pointer that points to any element in the vector will become invalid.
Considering this issue i have a couple of possible solutions. After each push_back to the vector, would it be a viable to check if a current capacity variable is exceeded by the actual capacity of the vector? And if so, fetch and overwrite the old pointers to the new ones? Would this guarantee to "catch" every case that invalidates pointers when performing a push_back?
Another solution that i've found is to instead save an index to the element and access it that way, but i suspect that is bad for performance when you need to continuously check the state of that element (every 1/60 second).
I am aware that other containers do not have this issue but i'd really like to make it work with a vector. Also it might be worth noting that i do not know in advance how many entities / components there will be.
Any input is greatly appreciated.
You shouldn't worry about performance of std::vector when you access its element only 60 times per second. By the way, in Release compilation mode std::vector::operator[] is being converted to a single lea opcode. In Debug mode it is decorated by some runtime range checks though.
If the user is going to store pointers to the objects, why even contain them in a vector?
I don't feel like it is a good idea to (poor wording)->store pointers to objects in a vector. (what I meant is to create pointers that point to vector elements, i.e. my_ptr = &my_vec[n];) The whole point of a container is to reference the contents in the normal ways that the container supports, not to create outside pointers to elements of the container.
To answer your question about whether you can detect the allocations, yes you could, but it is still probably a bad idea to reference the contents of a vector by pointers to elements.
You could also reserve space in the vector when you create it, if you have some idea of what the maximum size might grow to. Then it would never resize.
edit:
After reading other responses, and thinking about what you asked, another thought occurred. If your vector is a vector of pointers to objects, and you pass out the pointers to the objects to your clients, resizing the vector does not invalidate the pointers that the vector hold. The issue becomes keeping track of the life of the object (who owns it), which is why using shared_ptr would be useful.
For example:
vector<shared_ptr> my_vec;
my_vec.push_back(stuff);
if you pass out the pointers contained in the vector to clients...
client_ptr = my_vec[3];
There will be no problem when the vector resizes. The contents of the vector will be preserved, and whatever was at my_vec[3] will still be there. The object pointed to by my_vec[3] will still be at the same address, and my_vec[3] will still contain that address. Whomever got a copy of the pointer at my_vec[3] will still have a valid pointer.
However, if you did this:
client_ptr = &my_vec[3];
And the client is dereferencing like this:
*client_ptr->whatever();
You have a problem. Now when my_vec resized, &my_vec[3] is probably no longer valid, thus client_ptr points to nowhere.
If something is added to the vector that the pointer points to and the
capacity is exceeded, it is my understanding that the vector will
allocate new memory and every pointer that points to any element in
the vector will become invalid.
I once wrote some code to analyze what happens when a vector's capacity is exceeded. (Have you done this, yet?) What that code demonstrated on my Ubuntu with g++v5 system was that std::vector code simply a) doubles the capacity, b) moves all the elements from old to the new storage, then c) cleans up the old. Perhaps your implementation is similar. I think the details of capacity expansion is implementation dependent.
And yes, any pointer into the vector would be invalidated when push_back() causes capacity to be exceeded.
1) I simply don't use pointers-into-the-vector (and neither should you). In this way the issue is completely eliminated, as it simply can not occur. (see also, dangling pointers) The proper way to access a std::vector (or a std::array) element is to use an index (via the operator[]() method).
After any capacity-expansion, the index of all elements at indexes less than the previous capacity limit are still valid, as the push_back() installed the new element at the 'end' (I think highest memory addressed.) The elements memory location may have changed, but the element index is still the same.
2) It is my practice that I simply don't exceed the capacity. Yes, by that I mean that I have been able to formulate all my problems such that I know the required maximum-capacity. I have never found this approach to be a problem.
3) If the vector contents can not be contained in system memory (my system's best upper limit capacity is roughly 3.5 GBytes), then perhaps a vector container (or any ram based container) is inappropriate. You will have to accomplish your goal using disk storage, perhaps with vector containers acting as a cache.
update 2017-July-31
Some code to consider from my latest Game of Life.
Each Cell_t (on the 2-d gameboard) has 8 neighbors.
In my implementation, each Cell_t has a neighbor 'list,' (either std::array or std::vector, I've tried both), and after the gameboard has fully constructed, each Cell_t's init() method is run, filling it's neighbor 'list'.
// see Cell_t data attributes
std::array<int, 8> m_neighbors;
// ...
void Cell_t::void init()
{
int i = 0;
m_neighbors[i] = validCellIndx(m_row-1, m_col-1); // 1 - up left
m_neighbors[++i] = validCellIndx(m_row-1, m_col); // 2 - up
m_neighbors[++i] = validCellIndx(m_row-1, m_col+1); // 3 - up right
m_neighbors[++i] = validCellIndx(m_row, m_col+1); // 4 - right
m_neighbors[++i] = validCellIndx(m_row+1, m_col+1); // 5 - down right
m_neighbors[++i] = validCellIndx(m_row+1, m_col); // 6 - down
m_neighbors[++i] = validCellIndx(m_row+1, m_col-1); // 7 - down left
m_neighbors[++i] = validCellIndx(m_row, m_col-1); // 8 - left
// ^^^^^^^^^^^^^- returns info to quickly find cell
}
The int value in m_neighbors[i] is the index into the gameboard vector. To determine the next state of the cell, the code 'counts the neighbor's states.'
Note - Some cells are at the edge of the gameboard ... in this implementation, validCellIndx() can return a value indicating 'no-neighbor', (above top row, left of left edge, etc.)
// multiplier: for 100x200 cells,20,000 * m_generation => ~20,000,000 ops
void countNeighbors(int& aliveNeighbors, int& totalNeighbors)
{
{ /* ... initialize m_count[]s to 0 */ }
for(auto neighborIndx : m_neighbors ) { // each of 8 neighbors // 123
if(no_neighbor != neighborIndx) // 8-4
m_count[ gBoard[neighborIndx].m_state ] += 1; // 765
}
aliveNeighbors = m_count[ CellALIVE ]; // CellDEAD = 1, CellALIVE
totalNeighbors = aliveNeighbors + m_count [ CellDEAD ];
} // Cell_Arr_t::countNeighbors
init() pre-computes the index to this cells neighbors. The m_neighbors array holds index integers, not pointers. It is trivial to have NO pointers-into-the-gameboard vector.
Note: Performance is very critical in my application!
Allocate enough buffer storage for the worst case scenario is a requirement to avoid reallocation.
Look at this, this is how I usually use std::vector:
//On startup...
unsigned int currVectorSize = 0u;
std::vector<MyStruct> myStructs;
myStructs.resize(...); //Allocate for the worst case scenario!
//Each frame, do this.
currVectorSize = 0u; //Reset vector, very fast.
run algorithm...
//insert X elements in myStructs if condition is met
myStructs[currVectorSize].member0 = ;
myStructs[currVectorSize].member1 = ;
myStructs[currVectorSize].member2 = ;
currVectorSize++;
run another algorithm...
//insert X elements in myStructs if condition is met
myStructs[currVectorSize].member0 = ;
myStructs[currVectorSize].member1 = ;
myStructs[currVectorSize].member2 = ;
currVectorSize++;
Another part of the application uses myStructs and currVectorSize
I have a decision problem, should I use std::vector + resize + my own size variable OR std::vector + reserve + push_back + clear + size?
I don't like to keep another size variable floating around, but the clear() function is slow(linear time) and the push_back function have the overhead of bounds check. I need to reset the size variable in constant time each frame without calling any destructors and running in linear time.
Conclusion: I don't want to destroy my old data, I just need to reset the current size/current number inserted elements variable each frame.
If performance is critical, then perhaps you should just profile everything you can.
Using your own size variable can help if you can be sure that no reallocation is needed beforehand (this is what you do - incrementing currVectorSize with no checks), but in this case why use std::vector at all? Just use an array or std::array.
Otherwise (if reallocation could happen) you would still need to compare your size variable to actual vector size, so this will be pretty much the same thing push_back does and will gain you nothing.
There are also some tweaked/optimized implementations of vector like folly::fbvector but you should carefully consider (and again, profile) wheter or not you need something like that.
As for clearing the vector, check out vector::resize - it is actually guaranteed not to reallocate if you're resizing down (due to iterator invalidation). So you can call resize(0) instead of clear just to be sure.
I have a data structure that works like an unordered queue and a vector filled with objects of class A. I want to populate the queue one element at a time (using a push() function) with pointers to each of the objects in the vector.
This implementation needs to:
Keep track of the original order of the objects in the vector even as the pointers stored in the queue swap positions in accordance with a comparator and the values of the objects
Allow for the continued addition of objects to the vector (again, mindful of order)
Allow the objects to be edited according to their original order in the vector without needing to recopy everything to the queue (hence, queue of pointers rather than objects)
I've been beating my head against the wall for several hours now in an attempt to figure this out. Right now I have two solutions that both fail for different reasons.
The first is
for(auto i = vector.begin(); i < vector.end(); i++)
{
queue->push(new A (*i));
}
This one worked perfectly until it came time to edit the elements in vector, at which point I realized that it seemed to have no effect whatsoever on the values in the queue. Maybe the pointers got decoupled somewhere.
The second is
for(A* ptr = vector.data(); ptr <= (vector.data()+vector.size()-1); ptr++)
{
A** bar = new A*;
*bar = ptr;
queue->push(*bar);
}
As best I can tell, this one successfully matches up the pointers with objects in vector, but for some other reason I can't tell causes a core abortion after doing some additional operations on the queue (pop(), max(), etc).
If anyone out there can offer any advice, I would sincerely appreciate it.
Oh, and before I forget, as much as I would love to use shared_pointers or unique_pointers or boost, I'm limiting this to just the STL and vector, list and deque. No other containers.
Your first and third requirements can be met with pointers, and the implementation is not difficult. What I advise you to do is to not use auto since it will give you an iterator object and converting that to a pointer can be hard.
Regarding your second requirement, it cannot be done since adding things to the vector can trigger a reallocation of memory in order to increase the vector capacity, unless you know the max number of objects the vector should hold beforehand. For fulfilling all your requirements then, the best solution is to "link" the objects by using the vector index instead of pointers. This is also way simpler.
But then again, if you remove things from the vector, then you have to update the entire queue. The most flexible solution that will allow you to do pretty much everything is to use lists instead of vectors. But it can have performance impact and you have to ponder before making the choice.
To make it work with vector and pointers, here is what I would do:
class A { /* your class here */ };
vector<A> vec;
/* Avoid vector reallocating memory. */
vec.reserve(MAX_NUMBER_OF_OBJECTS);
/* Then, populate the vector. */
/* No need for fully populating it though. */
/* ... */
/* Populate the queue. */
queue<A*> q;
for(int i = 0; i < vec.size(); i++){
q.push(&vec[i]);
}
Okay, so i'm doing this game like a project where i have 3 different objects.
void Character::shoot(){
Shot* s = new Shot(blablabla);
shots.push_back(s);
}
This happens dynamically, and currently i dont delete the pointers so it has to be loads of pointers to shots in that vector after a little while.
I use Bot, Character and Shot, and as i said i need help with storing and removing a pointer to the shot dynamically, preferably from a vector. I've got it to work like i put all the shot objects in a vector, but they never disappear from there. And i want to delete them permanently from my program when they collide with something, or reaches outside my screen width.
You can use std::remove and std::erase on any std container to remove content:
Shot* to_be_removed = ...;
std::vector<Shot*>::iterator i = std::remove(shots.begin(),shots.end(),to_be_removed);
std::erase(i,shots.end());
delete (to_be_removed);//don't forget to delete the pointer
This works when you know the element you want to remove. If you don't know the element you must find a way to identify the elements you want removed. Also if you have a system to identify the element it could be easier to use the container iterator in order to do the removal:
std::vector<Shot*>::iterator i = ...;//iterator the the element you want to remove
delete (*i);//delete memory
shots.erase(i);//remove it from vector
Lastly if you want to remove all pointers from the container and delete all the items at the same time you can use std::for_each
//c++ 03 standard:
void functor(Shot* s)
{
delete(s);
}
std::for_each(shots.begin(),shots.end(),functor);
shots.clear();//empty the list
//or c++11 standard:
std::for_each(shots.begin(),shots.end(),[] (Shot * s){ delete(s); } );
//the rest is the same
Using simple vector methods
You can iterate trough std::vector and use erase() method to remove current shot:
std::vector<cls*> shots; // Your vector of shots
std::vector<cls*>::iterator current_shot = shots.begin(); // Your shot to be deleted
while( current_shot < shots.end()){
if((*current_shot)->needs_to_be_deleted()){
// Remove item from vector
delete *current_shot;
current_shot = shots.erase(current_shot);
} else {
(*current_shot)->draw();
++current_shot; // Iterate trough vector
}
}
erase() returns iterator to next element after removed element so while loop is used.
Setting values to null and calling std::remove()
Note that std::vector::erase() reorganize everything after delete items:
Because vectors use an array as their underlying storage, erasing
elements in positions other than the vector end causes the container
to relocate all the elements after the segment erased to their new
positions. This is generally an inefficient operation compared to the
one performed for the same operation by other kinds of sequence
containers (such as list or forward_list).
This way you may end up with O(n^2) complexity so you may rather set values to null and use std::remove() as suggested by juanchopanza in comment, Erase-Remove idiom:
int deleted = 0;
for( current_shot = shots.begin(); current_shot < shots.end(); ++current_shot){
if((*current_shot)->needs_to_be_deleted()){
// Remove item from vector
delete *current_shot;
*current_shot = null;
++deleted;
}
}
if( deleted){
shots.erase( std::remove(shots.begin(), shots.end(), null));
}
Using std::list
If you need large amount of shot creations and deletions std::vector may not be the best structure for containing this kind of list (especially when you want to remove items from the middle):
Internally, vectors use a dynamically allocated array to store their
elements. This array may need to be reallocated in order to grow in
size when new elements are inserted, which implies allocating a new
array and moving all elements to it. This is a relatively expensive
task in terms of processing time, and thus, vectors do not reallocate
each time an element is added to the container.
See link from Raxvan's comment for performance comparison.
You may want to use std::list instead:
List containers are implemented as doubly-linked lists; Doubly linked
lists can store each of the elements they contain in different and
unrelated storage locations. The ordering is kept by the association
to each element of a link to the element preceding it and a link to
the element following it.
Compared to other base standard sequence containers (array, vector and
deque), lists perform generally better in inserting, extracting and
moving elements in any position within the container for which an
iterator has already been obtained, and therefore also in algorithms
that make intensive use of these, like sorting algorithms.
The main drawback of lists and forward_lists compared to these other
sequence containers is that they lack direct access to the elements by
their position;
Which is great for removing items from the middle of the "array".
As for removing, use delete and std::list::erase():
std::list<cls*> shots;
std::list<cls*>::iterator current_shot;
// You have to use iterators, not direct access
for( current_shot = shots.begin(); current_shot != shots.end(); current_shot++){
if( (*current_shots)->needs_to_be_deleted()){
delete *current_shot;
shots.erase(current_shot); // Remove element from list
}
}
Using std::shared_ptr
If you have more complex program structure and you use the same object on many places and you can simply determine whether you can delete object already or you need to keep it alive for a little bit more (and if you are using C++11), you can use std::shared_ptr (or use different kind of "smart pointers" which delete data where reference count reaches zero):
// Pushing items will have slightly more complicated syntax
std::list< std::shared_ptr<cls>> shots;
shots.push_back( std::shared_ptr( new cls()));
std::list< std::shared_ptr<cls>>::iterator current_shot;
// But you may skip using delete
shots.erase(current_shot); // shared_ptr will take care of freeing the memory
Simply use "delete" to deallocate the memory:
vector<Shot*>::iterator i;
for(i = shoot.begin(); i != shoot.end(); ++i)
{
delete (*i);//delete data that was pointed
*i = 0;
}
shoot.clear();
This will delete all elements from the heap and clear your vector.