[Insight-developers] Lots of new warnings: Adding an alternative GetInverse() method to the transform hierarchy.

[Douglas Alan]

Luis Ibanez <luis.ibanez at kitware.com> wrote:

> The reason for returning TransformBase is to avoid dependencies
> with the Transform parameters, that will result in this GetInverse()
> method to have a signature that differs only on the return value.

If I understand you right, the issue is that if one wants the inverse,
for example, of a transform that is of type

   Transform<double, 4, 3>

then the inverse, if it exists, is of type

   Transform<double, 3, 4>

And there is no subtyping relationship between these two types.

Is that right?  If so, then that makes sense to me.

> Could you elaborate on the details of Astronomical transformations for
> which the GetInverse() method should be virtual ?

There's nothing special about our astronomical transformations that I
can think of, except that they will always be a subtype of
Transform<double, 3, 3> and are always invertible (at least for values
returned by the forward transform).

Consequently, it's more convenient for us if the inverse of a
Transform<double, 3, 3> is also a Transform<double, 3, 3>, rather than
being of type TransformBase.  If the former were the case rather than
the latter, then the result of Transform<double, 3, 3>::GetInverse()
wouldn't need to be downcast from TransformBase to Transform<double, 3,
3>.

Downcasting is distasteful where unnecessary (and potentially unsafe),
but in this case it seems to be necessary for the greater good of ITK.

|>oug

P.S. Is there a way with C++'s template mechanism to allow for
GetInverse() to return a Transform<> object if the second and third
template parameters are the same, and a TransformBase otherwise?

If there *is* a way to do this, I don't know of it, but I'm not up on
all the latest template metaprogramming techniques.