[Insight-developers] itk::Math:: limitations (was: Using Math::Floor in interpolation code?)

[Tom Vercauteren]

Hi Luis,

> Instead of "long long" you may want to work with the type
>
>                    ptrdiff_t
>
> which is the signed version of
>
>
>                    size_t
>
> In that way you don't have to use #ifdef to select the
> correct size.

As far as I understand it, ptrdiff_t is basically a long (32bits an
32bit machine, 64 on 64 machines), right? If that's correct and we
want a fast Round function that returns a ptrdiff_t, we still need
something along the lines of

ptrdiff_t Round(double x) {
# if SIZEOF_PTRDIFF_T == 8
 // fast 64 bits implementation when possible
 [...]
# elif  SIZEOF_PTRDIFF_T == 4
 // fast 32 bits implementation when possible
 [...]
#else
 // vanilla implementation
 [...]
#endif
}

That's because the fast implementations of round really depends on the
size of the return type.


> Also, the obstacle for creating multiple functions whose
> signature only differ by the return type is (for once)
> not only a Visual Studio 6 limitation, any C++ compliant
> compiler should reject that construction.

Right! I was missing coffee :)
Of course covariant return types only makes sense in a hierarchy of classes...

Would you be in favor of modifying the current signature of the
rounding functions (non-backward compatible) or using a new name for
the ptrdiff_t variant? In that case, what name should be choose
"LRound" or "lRound" made sense with longs but make somewhat less
sense with ptrdiff_t.

Tom