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 offloats. 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
getColorin 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"getColorcalls these implementations, and there is no circular reference.getColorin user code. In case it's a PCL color handler, the default implementation of "old"getColorwill 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.