Going up the object hierarchy - c++

Question

Hi so I've got some nice tree hierarchy of objects in program i'm working on. I've came across a problem with communicating the bottom to top way. How I have it set up right now is that in every constructor I pass a reference to object creating the new object. Simple structure would look like this:
[Controller] -> [World] -> [Object]
Going up one layer (from world to controller or from object to world) is OK. But where the problem starts to occur is when I try to go up 2 layers.
Here is a simplified structure of how I have set it up:
Controller.h:
#include "World.h"
Class Controller {
public:
Controller() {
_worlds.push_back(World(*this));
)
void update() { // Called on a loop from main program loop
_worlds[0].update(); // Calls update of active world, in this case world[0]
}
vector<World> _worlds;
Camera _camera; // class with checkIfInView function
}
World.h:
#Include "Object.h"
Class Controller;
Class World {
World(Controller& ref) : _controller(ref) {
_objects.push_back(Object(*this));
_controller._camera.doStuff(); // works OK
}
void update() {
for (auto& i : _objects)
i.update();
}
vector<Object> _objects;
Controller& _controller;
}
Object.h:
Class World;
Class Object {
Object(World& ref) : _world(ref) {}
void update();
World& _world;
}
Object.cpp:
#include "Controller.h"
#include "World.h"
void Object::update() {
_world._controller._camera.checkIfInView(*this); // Read access violation
}
Controller hold one single camera object which is responsible for what is being shown. What I need is a way for Objects to call checkIfInView to know if they should render or not. Is there any other way to do this or a way to fix it?
EDIT: Updated code.

Answer 1

The problem
Let's look at your nice chain, starting with the Controller constructor. As it's the top object of your hierarchy, it the start of the construction. I imagine that in main() you have something like
Controller c;
This will cause the constructor to be called:
Controller() {
_worlds.push_back(World(*this)); // !!!
}
World(*this) will create a new temporary world that you'll push into the vector of worlds of your controller. The temporary object only exists for the time of the expression in which it appears.
The temporary World will then be constructed with
World(Controller& ref) : _controller(ref) { // ref to controller is kept
_objects.push_back(Object(*this)); // ouch!!!
_controller._camera.doStuff(); // works OK
}
Now an object will be created which refers to *this world. Ouch!! Remember that that world is temporary ? At the end of the construction it will be deleted, so that all objects will refer to a C++ object that no longer exists and hence the UB which happen to produce the segmentation fault in your case.
The start of a solution
The design that you have is quite delicate. Think twice if you couldn't find a safer design pattern. If you want nevertheless to pursue in this direction, avoid creating objects using temporary items: create dynamically allocated ones instead.
Controller() {
_worlds.push_back(*new World(*this)); // !!! risk of leakage
}
The next thing would be to use pointers instead of references:
Controller() {
_worlds.push_back(new World(*this)); // risk of leakage
}
Of course, you'd need to change the rest of the code accordingly, to work with pointers.
The next thing would be to opt for shared pointers: this avoids risk of leakage:
Controller() {
_worlds.push_back(make_shared<World>(*this)); // risk of leakage
}
In the adaptation of your code you'd then need to make a difference between shared_ptr in your vectors, which refers to the object, and weak_ptr to the parten objects, to indicate tha the parent is now shared owned by the child but by another object.
A better solution ?
I warn you that it will not be a piece of cake. As soon as you have pointers, you'd need to take care of the rule of 3 for each class.
Many issues arise from:
1) the nested construction -> may be worth considering the builder design pattern
2) the risk of mixing of static objects and dynamically created objects, never knowing which kind is the parent. -> may be worth using a protected/private constructor and use a factory method for making sure that all objects are always dynamic objects.