Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix children[] array not deleted in deleteNodeRecurs function. #288

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from
Open

Fix children[] array not deleted in deleteNodeRecurs function. #288

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5a3f34a
Fix children[] array not deleted in deleteNodeRecurs function.
xinyiz Mar 23, 2020
c210dad
Fix children[] array not deleted in deleteNodeRecurs function.
xinyiz Mar 23, 2020
76cb6ec
Merge branch 'fix-deleteNodeRecurs' of https://github.com/xinyiz/octo…
xinyiz Mar 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions octomap/include/octomap/OcTreeBaseImpl.hxx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -705,9 +705,13 @@ namespace octomap {
// TODO delete check depth, what happens to inner nodes with children?
this->deleteNodeChild(node, pos);

if (!nodeHasChildren(node))
if (!nodeHasChildren(node)){
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason not to do this cleanup in deleteNodeChild() already?
It semantically belongs to the deletion of the (last) child, and doing it outside may lead to having to add the same routine to other contexts from where deleteNodeChild is called.

Copy link
Member

@ahornung ahornung Sep 12, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! The only reason I can think of is the (probably) less efficient call of "pruneNode(...)", which does the cleanup once after deleting all 8 child nodes (instead of checking for every single call of deleteNodeChild if it's empty already).

Copy link

@christofschroeter christofschroeter Sep 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, when you know you are deleting multiple children, you may not want to check after each deletion (which means iterating the 8 child pointers).

So I would suggest adding a parameter to deleteNodeChild() whether to cleanup, which in my opinion should have a default of true.
And if the cleanup is done internally, it might be an idea to return the result of the internal nodeHasChildren() from deleteNodeChild(), saving an extra query as in deleteNodeRecurs()

if (node->children != NULL){
delete[] node->children;
node->children = NULL;
}
return true;
else{
} else {
node->updateOccupancyChildren(); // TODO: occupancy?
}
}
Expand Down