Hi, the problem lies in your code. It is not a bug.
when you use
push_back a copy of what you are passing is made and stored in the vector. As ofNode relies on keeping a pointer to its parent when the vector creates this copy it messes up with the pointer, as the copy will have a pointer to the eleements that were constructed for the original.
There are several workarounds.
1 You can use a setup function in your void so the ofNode’s parenting is performed post copy on the actual object stored in the vector.
boids.back().setup(glm::vec3(ofGetWidth()/2, ofGetWidth() / 2,0));
void setup(glm::vec3 p)
vel = glm::vec3(0.1, 0.1, 0.1);
rWing.move(110, 0, 0);
This is the simplest solution but you can run into the problem that std::vector realocates itself when you expand it and that will mess up the pointers.
Although, if you are only pushing elements to the vector once during setup you can do the following
boids.resize(100);// which ever amount of boids you might want to have
for(auto& b: boids)// this is similar to the tipical for loop, it is a modern c++ thing. you type less.
b.setup(glm::vec3(ofGetWidth()/2, ofGetWidth() / 2,0));
if this works for you great, if not you will need to use either
std::vector<std::unique_ptr<Boid> to store the elements, and it will work regardless of the vector expanding and reallocating itself.
unique_ptr are the so called “smart pointers”, which will be in charge of deleting their allocated memory once destroyed, saving you from having to take care of such (which tended to be one of the biggest sources of memory leaks and bugs). This are a feature of modern C++ and its use is highly recommended and endorsed instead of using raw pointers. Their major difference is that that the
shader_ptr allows you to share that pointer and have several instances of a shared_ptr pointing to the same data, which is all managed by it internally. The unique_ptr does not allow you to have such sort of shared instances and you can not copy it, but it is the simplest one and introduces almost no overhead, while the shared_ptr does introduce a very slight overhead (probably unnoticed most of times).
if you use either of these smart pointers you dont need to change the Boid class
it should go like
// in ofApp.h
boids.emplace_back(make_unique<Boid>(glm::vec3(ofGetWidth()/2, ofGetWidth() / 2,0)));
// in ofApp.h
boids.push_back(make_shared<Boid>(glm::vec3(ofGetWidth()/2, ofGetWidth() / 2,0)));