You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, children is of type OcTreeDataNode, which means the OcTreeDataNode destructor is called for children, rather than the correct subclass destructor.
This breaks horribly for me with an OcTreeDataNode subclass whose destructor needs to be called.
The obvious fix is to make OcTreeDataNode's destructor virtual - unless there's an important reason not to :)
The text was updated successfully, but these errors were encountered:
The reason why there are no virtual functions in the octree nodes is to reduce memory. Declaring a virtual function will force the compiler to insert a vtable pointer, thus increasing the size of every node in the tree by 4 or 8 bytes. The nodes are not designed to be used polymorphically, all children of a node need to have the same type.
So this should be fixed in a different way, see for example the casts in getChild(i).
Thanks for the explanation - I was thinking of code reuse more than size, but obviously even 4 bytes per node are bound to make a noticeable difference at the scale octomap operates on :)
So node classes that implement their own destructor should just cast the children array to their own type (or use their own getChild() method), right?
The destructor for
OcTreeDataNode
(octomap/include/octomap/OcTreeDataNode.h:65) does adelete
on each of the node's children.However, children is of type
OcTreeDataNode
, which means theOcTreeDataNode
destructor is called for children, rather than the correct subclass destructor.This breaks horribly for me with an
OcTreeDataNode
subclass whose destructor needs to be called.The obvious fix is to make
OcTreeDataNode
's destructor virtual - unless there's an important reason not to :)The text was updated successfully, but these errors were encountered: