Add new overload of PointCloudColorHandler::getColor()
#3187
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add
PointCloudColorHandler::getColor()
that returns VTK data array and deprecate oldgetColor(vtkSmartPointer<vtkUnsignedCharArray>&)
in its favor. Follow-up to the discussion in #3176.In the process of implementing my propsal from #3176 I realized that we can not change the signature to use
vtkSmartPointer<vtkUnsignedCharArray>
since some of the handlers actually produce arrays offloat
s. However, the idea to always allocate data array insidegetColor()
and return it as a smart pointer was implementable, so here we go.Note the two default implementations of
getColor
in the base that are provided for backwards compatibility. They use each other, which may seem like a circular reference, however in practice should not be a problem. The reason to implement them this way is to support two use-cases in downstream projects:getColor
(because it was pure virtual, thus required to be overriden). Therefore the "new"getColor
calls these implementations, and there is no circular reference.getColor
in user code. In case it's a PCL color handler, the default implementation of "old"getColor
will call the newgetColor
, which is overriden in every PCL color handler, so again no circular reference. In case it's a user color handler, according to item 1 it will again have its own override of the "old"getColor
, so no circular references.