[Insight-developers] Proposal: Changing NumericTraits of vector types to use macros

[Bradley Lowekamp]

Hello,

Yes, I was questioning if the newly added constructor needed to be explicit to prevent it from accidentally acting as a conversion when not intended. As you point out, Vector and CovariantVector already have this interface. So what you did is correct and follows.

What I was thinking of is the following constructor which has caused me some problems before. I have made this explicit in my code but may not meet backwards compatibility standard:

 /** Constructor with size. Size can only be changed by assignment */
itk::Array::Array(unsigned int dimension);


I am just cautious of single argument constructors!

Brad


On Nov 30, 2009, at 11:16 AM, Gaëtan Lehmann wrote:

> 
> Le 30 nov. 09 à 15:55, Bradley Lowekamp a écrit :
> 
>> Do we need the explicit keyword here?
>> 
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkFixedArray.h?root=Insight&r1=1.45&r2=1.46
> 
> I'm not sure to understand what you mean with "explicit keyword".
> If it is the constructor added here, yes, we have to add it to have the same interface than in other similar classes, like CovariantVector or Vector, and be able to use the same macros to define Zero and One traits.
> 
> Do you think it can be done without it?
> 
> Gaëtan
> 
> 
>> 
>> On Nov 30, 2009, at 4:38 AM, Gaëtan Lehmann wrote:
>> 
>>> 
>>> Brad, Luis,
>>> 
>>> I have already commited some code on that subject, while working on two long standing bugs in wrapitk - the missing NumericTraits while building with dimension 4, and the empty NumericTraits< FixedArray< * > > classes.
>>> 
>>> I've modified some macros from RGBAPixel numeric traits to refactor the numeric traits of FixedArray, Vector, CovariantVector and SymmetricSecondRankTensor.
>>> 
>>> Regards,
>>> 
>>> Gaëtan
>>> 
>>> 
>>> 
>>> Le 28 nov. 09 à 18:09, Luis Ibanez a écrit :
>>> 
>>>> Hi Brad,
>>>> 
>>>> Yes, it is a good idea to propagate the use of Macros for other NumericTraits.
>>>> 
>>>> We took a historical detour in the development of the NumericTraits, and
>>>> only come to use the convenience macros with the most recently added
>>>> classes. It will be great to back-port this practice to the initial vector-like
>>>> classes.
>>>> 
>>>> As you pointed out, using the macros will result in more consistent and
>>>> maintainable code.
>>>> 
>>>> 
>>>>  Luis
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------------
>>>> On Fri, Nov 27, 2009 at 11:16 AM, Bradley Lowekamp
>>>> <blowekamp at mail.nih.gov> wrote:
>>>>> Hello,
>>>>> The next logical step after adding itk::NumericTraits<long long> is to also
>>>>> add it to all the vector types that also have numeric traits
>>>>> defined. Unfortunately I am lazy, and manually going through all these
>>>>> files, and close to 5,000 lines of code, to perform copy, paste, edit seems
>>>>> like too much work.
>>>>> Looking at itkNumericTratisVariableLengthVectorPixel.h:
>>>>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkNumericTraitsVariableLengthVectorPixel.h?revision=1.7&root=Insight&view=markup
>>>>> This seems to have an elegant macro which both does total template
>>>>> specialization and partial specialization when needed. It seems like much
>>>>> less work to implement similar macros in each file. One important change I'd
>>>>> make to similar macros for other types is to make the "ElementTypes" (which
>>>>> are needed for bcc) private so as to not add additional traits that have not
>>>>> been defined as part of the interface.
>>>>> As a "good" side effect, this will help maintainability and correct errors
>>>>> that currently exist in the traits. For example  the many numeric traits for
>>>>> for char vector types still have the char vector type as the PrintType,
>>>>> which is wrong because it'll print ASCII value instead of numbers. There are
>>>>> also missing trait types in many vector types as well. For example the
>>>>> CovariantVector traits are missing the FloatType.
>>>>> 
>>>>> Brad
>>>>> 
> 

========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20091130/5e5b7464/attachment.htm>