Smart pointer design

Hi. I am completing the pointers design in WOLF (see this design). I added pointers from StateBlocks to their owners. This will ease up managing their removal properly, as they need to be unregistered from the wolf problem so that this can communicate it to the solver.

My idea is to put all this functionality just inside the StateBlock destructor.

@joanvallve , I think you already had this idea long ago. I think I am facing the same issue, and I think adding the up pointer is the way to go. Especially when derived classes incorporate additional StateBlocks (for example, FrameIMU has two additional blocks).

Up and down pointers are as always: down is shared, up is weak.

A second thought:

All nodes having StateBlocks (Frames, Landmarks and Sensors) will actually have a list<> or vector<> of StateBlock pointers. This way, freeing all of them will be easy.

Now, each state block in a Node has a dedicated pointer. In derived classes, the developer has to remember to remove the state blocks from the list of state blocks in Problem, for the solver to realize that this state block is no longer there.

Using a list, or vector, the destructor of the Base class owning the state blocks can just remove all pointers from the list in Problem, and the Derived classes do not need to care about this. This complies with the functionality that we desire for the core library, and frees the developers of derived classes to take care of the wolf tree integrity.

Moreover, this design flattens all the pieces of the wolf tree, so that all share a similar structure: all are Nodes, with lists of pointers to other Nodes. In this sense, a StateBlock could perfectly be a Node, just like all other nodes.

Opinions welcome.

J

Changed title: Adding up pointer from StateBlock to its owner. → Smart pointer design

I implemented, finally, lists of shareds to stateblocks,

These lists are in the nodes (they are in fact vectors since we need random access to implement getPPtr (), getOPtr(), etc. ). And lists in Problem for managing the solver.

Closing. See #100 (closed)

Status changed to closed