BUG: Fix printing of values in MetaDataObject

[blowekamp]

Also removes dead code related to METADATAPRINT

Does not currently add printing for std::vector.

Fix #1454
Near duplicate of: #4368
Co-Author: Pablo Hernandez-Cerdan [email protected]

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

[dzenanz]

Code looks elegant. Hopefully it works!

[blowekamp]

This also does not make use of itk::Matrix::PrintSelf. The LightObject class provides a standard Print, and PrintSelf method ( with indent). The MetaDataObject class is derived from the LightObject, while the MetaDataDictionary is not.

[dzenanz]

Do the image directions and other matrices get printed correctly or as [UNKNOWN PRINT CHARACTERISTICS]?

[blowekamp]

The itk::Matrix and itk::Array classes get printed with their "operator<<". The new Matrix::PrintSelf (#4772) is not used.

std::vector still get printed with [UNKNOWN PRINT CHARACTERISTICS]

[phcerdan]

Looks good and thanks for the follow up.
Why aren't we adding support for std::vector or other iterables?
Seems like a good opportunity.

PS: In any case, this looks good as it is. It fixes the bug. No need to go for the generalization to print other iterables. But maybe good to have it in mind for the future.

[phcerdan]

Looks good!
In the future, we could look up on how to print iterables in a general way.

[dzenanz]

Could this operator be used?

[blowekamp]

Could this operator be used?

I ran into issue with the two approaches I tried to use that overloaded operator. Perhaps this can be a second PR?

[N-Dekker]

Please don't open an unnamed namespace in a header file (*.h, *.hxx). The compiler should have produced a warning! C++ Core Guidelines: Don’t use an unnamed (anonymous) namespace in a header

[dzenanz]

Looks like a good excuse for an immediate follow-up? 😄 Is there also some chance for you tackle std::vector printing?

[blowekamp]

@N-Dekker What is the alternative suggestion? Should move the classes to ITK's meta programming sub namespace?

[N-Dekker]

Should move the classes to ITK's meta programming sub namespace?

Good question... is the intention to have has_Print and has_output_operator as part of the public interface, for end-users? Then they could go into the meta programming sub-namespace. Or they could just remain in the root of the itk namespace. But then they should still be moved from the ".hxx" file into a ".h" file

Otherwise, is the intention to make clear to users that has_Print and has_output_operator are just implementation details? Then we could place them into some implementation-detail-namespace. We could for example name the namespace "itkMetaDataObjectImplementationDetail".

A third option: If you want to entirely hide them away from the end-users, you could probably make them privately nested types of MetaDataObject.