[Insight-developers] InteriorExteriorSpatialFunction and subclasses

[Brad King]

Hello, all:

The current problems on the GCC 3.0 dashboard build are partially due to
problems with the EllipsoidInteriorExteriorSpatialFunction class.

Its declaration is

template <class T, unsigned int VImageDimension=3>
class ITK_EXPORT EllipsoidInteriorExteriorSpatialFunction :
 public InteriorExteriorSpatialFunction<VImageDimension>

which uses the default argument provided by
InteriorExteriorSpatialFunction for its second argument.  This second
argument is Point<double,VImageDimension>, which hardcodes the point
representation type, and pays no attetion to the value of "T" in the first
argument of EllipsoidInteriorExteriorSpatialFunction.

Some of the other subclasses of InteriorExteriorSpatialFunction have only
a dimension parameter, which prevents problems like the one currently on
the dashboard, but totally restricts the function's point representation,
which restricts its usage with filters.

These problems are making the function hierarchy almost unusable.  It
seems only a few combinations of template arguments with certain filters
will produce usable code in the template instantiation.  Now all the
complexity of templated classes gains us nothing.

This should be discussed on today's TCON.  I don't know what we can do
about it for the beta release.  However, it presents further motivation
for an alternative to the amount of templating currently in the toolkit.  
I'm working on two alternative approaches for a re-design of the way
classes and filters are written.  I'll go over them with Will, and he can
bring them up for discussion at the February meeting.

-Brad