STYLE: Replace itk::NumericTraits<unsigned int>::OneValue() with 1

[N-Dekker]

Follow-up to pull request #4460 commit 5d746cc
"STYLE: Replace NumericTraits<unsigned int>::ZeroValue() with 0U"

[dzenanz]

Does 1 vs 1u make any difference?

[N-Dekker]

Does 1 vs 1u make any difference?

In practice, when you assign the value (1 or 1u) to a variable of a built-in type, it does not make a difference at all. So it's just a matter of style 😃

[blowekamp]

I am pretty sure at some point there was a compiler warning flag used that warned about conversions from int to unsigned int, and the draconian usage itk::NumericTraits was used to help determine where real conversion issues were occurring.

[N-Dekker]

itkOBJMeshIO.cxx does m_NumberOfCellPixelComponents = 3 without u as well.

ITK/Modules/IO/MeshOBJ/src/itkOBJMeshIO.cxx

Line 171 in 45ca040

this->m_PointDimension = 3;

[N-Dekker]

If anyone insists on 1U, that's OK to me as well, I can amend the commit if anyone wants to. I'm just slightly in favor of 1. Because of its simplicity 😃

BTW, I would use uppercase U (rather than lower case) in order to be consistent with the L for long. Or UL for unsigned long.

[N-Dekker]

I am pretty sure at some point there was a compiler warning flag used that warned about conversions from int to unsigned int, and the draconian usage itk::NumericTraits was used to help determine where real conversion issues were occurring.

Thanks for explaining, @blowekamp. Nowadays I think the main reason for using itk::NumericTraits would be to support pixel types in a generic way. Specifically, itk::NumericTraits<PixelType>::OneValue() returns 1 when the pixel type is int, while it returns {1, 1, 1} for an RGB pixel type.

[blowekamp]

I am pretty sure at some point there was a compiler warning flag used that warned about conversions from int to unsigned int, and the draconian usage itk::NumericTraits was used to help determine where real conversion issues were occurring.

Thanks for explaining, @blowekamp. Nowadays I think the main reason for using itk::NumericTraits would be to support pixel types in a generic way. Specifically, itk::NumericTraits<PixelType>::OneValue() returns 1 when the pixel type is int, while it returns {1, 1, 1} for an RGB pixel type.

The other case to consider is with itk::SizeType or std::std size type. The size of "long" and "long long" vary across systems and can change based on the word size for the architecture on some, but not other platforms.

[N-Dekker]

Nowadays I think the main reason for using itk::NumericTraits would be to support pixel types in a generic way. Specifically, itk::NumericTraits<PixelType>::OneValue() returns 1 when the pixel type is int, while it returns {1, 1, 1} for an RGB pixel type.

The other case to consider is with itk::SizeType or std::std size type. The size of "long" and "long long" vary across systems and can change based on the word size for the architecture on some, but not other platforms.

OK, but for a built-in integer type (or a typedef or alias of a built-in integer type), std::numeric_limits<T> typically offers everything one may need. So in that case, I would prefer std::numeric_limits<T>, rather than itk::NumericTraits<T>.