[Insight-users] Re: [Insight-developers] THE CONCEPT CHECKING
REVOLUTION : Please review your filters
Miller, James V (GE, Research)
millerjv at crd.ge.com
Fri Feb 17 13:21:16 EST 2006
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