-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Fix SampleConsensusModel constructor to not use a virtual function #6305
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.
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 SampleConsensusModel constructor to not use a virtual function #6305
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay!
Maybe a dumb question, but what is the possible danger with calling setInputCloud
from the constructor here?
SampleConsensusModel (const PointCloudConstPtr &cloud, | ||
const Indices &indices, | ||
bool random = false) | ||
SampleConsensusModel (const PointCloudConstPtr &cloud, const Indices &indices = Indices(), const bool random = false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could adding a default value for indices
not create a possible ambiguity if only the cloud
parameter is given? Then there would not be a way to distinguish between this ctor and SampleConsensusModel (const PointCloudConstPtr &cloud, const bool random = false)
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is definitely ambiguous. This has been fixed by removing the default for indices.
From my understanding, the danger is that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still do not see the specific danger in this case since SampleConsensusModel
does not have a parent class, so as far as I can see, the only version of setInputCloud
that could be called from the constructor is the one in SampleConsensusModel
(as one would expect). But I guess following the general rule to not call a virtual function from a constructor is still a good idea. Thanks!
Calling virtual functions from a constructor is considered dangerous. This removes the call of the virtual function
setInputCloud
by setting the indices. This also simplifies some of the duplicate code in the constructors.