[Insight-users] Re: [Insight-developers] THE CONCEPT CHECKING
REVOLUTION : Please review your filters
Miller, James V (GE, Research)
millerjv at crd.ge.com
Mon Feb 20 10:35:36 EST 2006
Gaetan,
I added the concepts to the Wiki. They need better names. After the next release,
we can add them to itkConceptChecking.h
Jim
-----Original Message-----
From: Gaetan Lehmann [mailto:gaetan.lehmann at jouy.inra.fr]
Sent: Sunday, February 19, 2006 4:11 PM
To: Miller, James V (GE, Research)
Cc: Luis Ibanez; Brad King; Insight Users; Insight Developers List
Subject: Re: [Insight-users] Re: [Insight-developers] THE CONCEPT
CHECKING REVOLUTION : Please review your filters
Would it be possible to add those 2 checks (int and real types) in
itkConceptChecking.h and in the wiki ? It would help to help :-)
On Friday 17 February 2006 19:21, Miller, James V (GE, Research) wrote:
> NumericTraits has methods has static boolean constants like is_integral.
>
> So a concept check to force integral pixel types would look something like
> the Signed concept. Here's a first guess:
>
> template <typename T>
> struct Integral
> {
> typedef Integral Self;
> itkStaticConstMacro(IsIntegral, bool, NumericTraits<T>::is_integral);
> struct Constraints
> {
> typedef Detail::UniqueType_bool<true> TrueT;
> typedef Detail::UniqueType_bool<itkGetStaticConstMacro(IsIntegral)>
> IntegralT; void constraints()
> {
> IntegralT a = TrueT();
> Detail::IgnoreUnusedVariable(a);
> }
> };
>
> itkConceptConstraintsMacro();
> };
>
>
> -----Original Message-----
> From: insight-users-bounces+millerjv=crd.ge.com at itk.org
> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
> Luis Ibanez
> Sent: Friday, February 17, 2006 12:50 PM
> To: Gaetan Lehmann
> Cc: Brad King; Insight Users; Insight Developers List
> Subject: [Insight-users] Re: [Insight-developers] THE CONCEPT CHECKING
> REVOLUTION : Please review your filters
>
>
>
> Hi Gaetan,
>
> Thanks for your enthusiastic response, and for updating
> the Wiki table with the definitions of the Concepts.
>
>
> The term "Convertible" actually refers to "casting".
> Which is a bit ambiguous since, the fact that some types
> can be casted, doesn't really mean that the conversion
> will not introduce any problems. So, this concept
> simply requires type A to have an assignment operator
> with type B as argument, or a copy constructor with
> type B as argument.
>
>
> We could have strict type checking with specific types
> by using the RTTI with expressions such as:
>
>
> if( typeid( int ) == typeid( T ) )
> {
> std::cout << "Equal" << std::endl;
> }
> else
> {
> std::cout << "Different" << std::endl;
> }
>
>
>
> using these tests as building blocks we could create more
> generic ones for concepts such as "any integer type".
>
>
> This las case that you mention is actually where we need
> more help from the developers of the filters, because
> these are the cases that we will not be able to figure
> out on our own. E.g. we will see that the filter compiles
> and therefore it seems to be ok.
>
>
> As you pointed out, there is a close connection between
> this concept checking effort, and the wrapping. We are
> interested on finding ways of improving one using the
> other.
>
>
> Please let us know if you have any suggestions
> along those lines.
>
>
>
> Thanks
>
>
> Luis
>
>
>
> ========================
>
> Gaetan Lehmann wrote:
> > Hi,
> >
> > I'm glad to see this revolution, especially because it would make life
> > easier to create the wrappers.
> >
> > However, I'm not sure to understand all the checkers: for example, what
> > is the Convertible one ?
> > I think a more precise description would be nice (I have already copied
> > the description for the code source to the wiki, but I'm afraid it's
> > not enough in that case)
> >
> > Is it possible to do the following check ? They seem important, because
> > without them, the build can succeed, but the result produced can be
> > wrong: - type is integer (signed/unsigned char/short/int/long/...)
> > - type is real (float/double/long double/...)
> >
> > Gaetan
> >
> > On Fri, 17 Feb 2006 02:40:42 +0100, Luis Ibanez
> >
> > <luis.ibanez at kitware.com> wrote:
> >> 1. THE PROBLEM
> >>
> >> Given that ITK was designed and implemented using
> >> Generic Programming, most of the classes are templated
> >> over totally generic types. However, some classes have
> >> expectations about the capabilities of those types, and
> >> those expectations are not always made explicit in the
> >> code or in the documentation.
> >>
> >> For example, some image filters are intended to be used
> >> with images whose pixel type is float or double.
> >> Instantiating those filters with image of other pixel
> >> type will result in compilation errors, or run time
> >> errors.
> >>
> >>
> >>
> >>
> >> 2. THE SOLUTION
> >>
> >> The requirements over the types can be made explicit by adding
> >> the notion of Concept Checking. This is done by introducing a
> >> number of macros and helper templates that verify early on
> >> whether a type provides the capabilities that are expected by
> >> the filter or not.
> >>
> >>
> >> A set of "concepts" have been created in the file:
> >>
> >> Insight/Code/Common/
> >> itkConceptChecking.h
> >>
> >>
> >> They include features such as: requiring that a pixel
> >> type provides a multiplication operator, or an assignment
> >> operator. Other concept may be to require that the dimension
> >> of the input image matches the dimension of the output image.
> >>
> >>
> >> These concepts should be introduced on every filter in order
> >> to make this mechanism effective.
> >>
> >> Every filter may have many different concepts that ought
> >> to be introduced in the code. It is therefore not trivial
> >> to implement a decent coverage of concept checking. The
> >> support of the developers community is fundamental for
> >> managing successfully this monumental task.
> >>
> >>
> >>
> >>
> >>
> >> 3. THE ACTION PLAN
> >>
> >> Amy Squillacote (at Kitware) has courageously accepted the
> >> challenge of introducing the concepts into the ITK filters.
> >>
> >> Since there is a long list of filters, and a long list of
> >> concepts. This process requires the assistance of most of
> >> the developers. In particular, for defining what filters
> >> ought to have what concepts.
> >>
> >>
> >>
> >> For this purpose, Amy has created a Wiki Table with the
> >> list of existing concepts:
> >>
> >> http://www.itk.org/Wiki/Proposals:Concept_Checking
> >>
> >>
> >>
> >> as well as a table with the list of candidate filters:
> >>
> >> http://www.itk.org/Wiki/ConceptChecking:List_of_Filters
> >>
> >>
> >>
> >> The numbers in the columns of the second table correspond
> >> to the concepts listed in the first table. The purpose
> >> of the second table is to indicate what concept checker
> >> should be introduced on every filter.
> >>
> >>
> >> We will need the help of all the developers in order to
> >> fill up this table correctly.
> >>
> >>
> >> Please review this table and identify the filters that you
> >> are familiar with and help us fill in the list of concepts
> >> that should be checked for that filter.
> >>
> >>
> >> Please note that Wiki pages are not very good for managing
> >> simultaneous edits by multiple authors. It is therefore
> >> convenient to find a way of preventing multiple developers
> >> from updating the table simultaneously. Any suggestions
> >> on how to do this are welcome.
> >>
> >>
> >> All these changes are intended to be introduced after we
> >> cut the release of ITK 2.6.
> >>
> >>
> >> Please let us know if you have any questions or concerns.
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >> Luis
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Insight-developers mailing list
> >> Insight-developers at itk.org
> >> http://www.itk.org/mailman/listinfo/insight-developers
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
More information about the Insight-developers
mailing list