[Insight-developers] InteriorExteriorSpatialFunction and subc lasses

Fri, 18 Jan 2002 09:56:03 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1A030.40295710
Content-Type: text/plain

Here are my first thoughts.

template T on the EllipsoidInteriorExteriorSpatialFunction is unnecessary.  It is only used for
specifying the principal axes of the ellipse.  Doubles would be fine for this data type. I cannot
imagine needed a different representation for orientation.

'Course, this is not the question at hand.

I think EllipsoidInteriorExteriorSpatialFunction should have the same template parameters as
InteriorExteriorSpatialFunction. So InteriorExteriorSpatialFunction sets the range data type to be
"bool" on SpatialFunction.

Declaration for InteriorExteriorSpatialFunction
template <unsigned int VImageDimension=3,typename TInput=Point<double,VImageDimension> >
class ITK_EXPORT InteriorExteriorSpatialFunction : public  SpatialFunction<bool, VImageDimension,
TInput >

Declaration for EllipsoidInteriorExteriorSpatialFunction
template <unsigned int VImageDimension=3,typename TInput=Point<double,VImageDimension> >
class ITK_EXPORT EllipsoidInteriorExteriorSpatialFunction : public
InteriorExteriosSpatialFunction<VImageDimension, TInput >

-----Original Message-----
From: Brad King [ mailto:brad.king@kitware.com <mailto:brad.king@kitware.com> ]
Sent: Friday, January 18, 2002 9:34 AM
To: Insight Developers
Subject: [Insight-developers] InteriorExteriorSpatialFunction and
subclasses

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

_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers
<http://public.kitware.com/mailman/listinfo/insight-developers> 

------_=_NextPart_001_01C1A030.40295710
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE></TITLE>

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
Here are my first thoughts. template T on the 
EllipsoidInteriorExteriorSpatialFunction is unnecessary.&nbsp; It is only used 
for specifying the principal axes of the ellipse.&nbsp; Doubles would be fine 
for this data type. I cannot imagine needed a different representation for 
orientation. 'Course, this is not the question at hand. I think 
EllipsoidInteriorExteriorSpatialFunction should have the same template 
parameters as InteriorExteriorSpatialFunction. So 
InteriorExteriorSpatialFunction sets the range data type to be "bool" on 
SpatialFunction. Declaration for 
InteriorExteriorSpatialFunction template &lt;unsigned int 
VImageDimension=3,typename TInput=Point&lt;double,VImageDimension&gt; 
&gt; class ITK_EXPORT InteriorExteriorSpatialFunction : public&nbsp; 
SpatialFunction&lt;bool, VImageDimension, TInput &gt; Declaration 
for EllipsoidInteriorExteriorSpatialFunction template &lt;unsigned 
int VImageDimension=3,typename TInput=Point&lt;double,VImageDimension&gt; 
&gt; class ITK_EXPORT EllipsoidInteriorExteriorSpatialFunction : public&nbsp; 
InteriorExteriosSpatialFunction&lt;VImageDimension, TInput 
&gt; -----Original Message----- From: Brad King [<A 
href="mailto:brad.king@kitware.com">mailto:brad.king@kitware.com</A>] Sent: 
Friday, January 18, 2002 9:34 AM To: Insight Developers Subject: 
[Insight-developers] InteriorExteriorSpatialFunction 
and subclasses 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 &lt;class T, unsigned int VImageDimension=3&gt; class 
ITK_EXPORT EllipsoidInteriorExteriorSpatialFunction : &nbsp;public 
InteriorExteriorSpatialFunction&lt;VImageDimension&gt; which uses the 
default argument provided by InteriorExteriorSpatialFunction for its second 
argument.&nbsp; This second argument is Point&lt;double,VImageDimension&gt;, 
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.&nbsp; It seems only a few combinations of template arguments with 
certain filters will produce usable code in the template instantiation.&nbsp; 
Now all the complexity of templated classes gains us nothing. This 
should be discussed on today's TCON.&nbsp; I don't know what we can do about 
it for the beta release.&nbsp; However, it presents further motivation for an 
alternative to the amount of templating currently in the toolkit.&nbsp; I'm 
working on two alternative approaches for a re-design of the way classes and 
filters are written.&nbsp; I'll go over them with Will, and he can bring them 
up for discussion at the February 
meeting. -Brad _______________________________________________ Insight-developers 
mailing list Insight-developers@public.kitware.com <A target=_blank 
href="http://public.kitware.com/mailman/listinfo/insight-developers">http://public.kitware.com/mailman/listinfo/insight-developers</A> </BODY></HTML>

------_=_NextPart_001_01C1A030.40295710--