-
-
Notifications
You must be signed in to change notification settings - Fork 691
Overload the stream insertion operator for types that are missing it #513
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
Comments
Yes, this is still relevant. |
Looking forward to reviewing the contribution! |
Hi again @dzenanz! As far as I am able to see the problems with printing fundamental types from As for native arrays and
W.r.t.
can you give me some examples of where they are printed currently and how you would like them printed/formatted? |
And of course printing instances of these types as ivars now that it is convenient to print them. |
@ChristianJacobsen contributions are always welcome 💯, and as @dzenanz says, this is still relevant. It would be awesome to finally have all necessary overloads in ITK ! So thanks for considering this 👍. Besides what @dzenanz pointed, section C.21 of the ITK SW Guide gives some more guidance about ivar printing in ITK. Essentially we would like to overload the
That would allow us to be able to:
PR #512 is related to this. Essentially, all ivars are expected to be printed in a method's And some other times we may still encounter loops to print some ivars due to a lacking support for the overload. Some other times ivars are serialized but the lack of appropriate support makes their address to be printed instead of their content (or some more meaningful information), or the Booleans have not yet got the corresponding treatment either (cf. this comment), and at times their are directly serialized to their integer values, other times an A nice side benefit of printing all ivars is that by doing so at times we identify find some ivars that have not been initialized, which is an undesirable situation, and may lead to a bug. So printing all ivars, hopefully using such useful overloads, is important. Many of the PRs that have as subject Hope this helps. Thanks @ChristianJacobsen . |
@ChristianJacobsen Another good candidates to get this enhancement are these two:
Or the
One would call Or still, removing the need for the boilerplate code to check for null raw pointers, as in:
Thanks. |
Hi @jhlegarreta! Sorry for the late reply. Things at work are just so hectic at the moment that I barely have any spare time left. I will continue to look at this when my schedule clears up. Feel free to reassign responsibility should someone else want to do it instead. Thank you for the tip about |
@ChristianJacobsen no worries. Take your time. Thanks. |
@dzenanz @jhlegarreta Can you please prioritize completing this issue for the next milestone? |
Sadly, I cannot definitely afford addressing this in the near term. |
Description
Overload the stream insertion operator for types that are missing it.
Expected behavior
To be able to print any data structure with a single line, e.g.:
Actual behavior
Developer's are forced to iterate over such structures to get them printed (usually in the
PrintSelf
method), e.g.:Additional information
Some fundamental ITK types (e.g.
IndexTypes
,SizeType
,SpacingType
,OffsetType
,DirectionType
,OffsetTable
,RegionType
) either seem not to have such an overload or it is just because some filters (itkImageConstIteratorWithIndex.h
,itkImageIORegion.h
,itkNeighborhood.h
,itkImportImageFilter.h
,itkConstNeighborhoodIterator.h
,itkImportImageFilter.hxx
,itkDisplacementFieldJacobianDeterminantFilter.h
,itkGaussianBlurImageFunction.h
,itkEllipsoidInteriorExteriorSpatialFunction.h
) that declare ivars of such types are not using the correct types, since it looks weird that such fundamental types do not have the stream insertion operator overload.Other more exotic type aliases (
GradientType
,StrideTable
,SeedsContainerType
,WeightsType
,ErrorArrayType
,ExtentArrayType
) would also deserve some investigation, as well as other aliases that are not consistent with the toolkit convention for the intended use (e.g.InputType
initkEllipsoidInteriorExteriorSpatialFunction.h
).Finally, other data structures that are also missing such an overload are regular arrays, e.g.
in
itkBSplineControlPointImageFunction.h
oritkGaussianDerivativeImageFuncton.h
or
in
itkScalableAffineTransform.h
.std::list
types (e.g.itkHoughTransform2DCirclesImageFilter.h
oritkHoughTransform2DLinesImageFilter.h
).Or
vnl_matrix
matrix (e.g.itkBSplineScatteredDataPointSetToImageFilter.h
).This is related to #512.
The text was updated successfully, but these errors were encountered: