[Insight-developers] itk::Index, itk::Offset, ... as subclass of itk::FixedArray?

Tom Vercauteren tom.vercauteren at m4x.org
Tue Nov 16 10:56:36 EST 2010


Hi all,

On Tue, Nov 16, 2010 at 16:35, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Gaetan,
>
> Probably only historical reasons...
>
> I don't see why we couldn't make the itk::Index and
> the itk::Offset be derived classes of the itk::FixedArray.
>
> Note however that Dave Cole is working hard on
> fixing the Windows 64 bits issues, so you may want
> to coordinate those changes (since the itk::Index and
> the itk::Offset are at the heart of the 64bits problem).
>
> --
>
> Regarding the intentional lack of a default constructor,
> we may have to run these experiments again.  I would
> suspect that it is still a valid issue, given that this relates
> to making the itkFixedArray appear as plain-old-data,
> instead of as a class. (there was also an issue of padding
> if I remember correctly...)

Indeed, currently it is still easy to access the memory help by an
  itk::Image< itk::Vector<float,2>, 2 >
by a simple
  float * floatptr = image->GetBufferPointer()[0].GetDataPointer()

Not sure if it is standard conformant since itk::Vector seems to be
only POD like and not strictly POD but at least it works on the
systems I have tested so far. This is important to avoid copying
memory between different libraries.

This works because itk::Vector inherits from itk::FixedArray and is
also POD-like. The less POD it becomes the more fragile my hypothesis
becomes. Remember that we had to remove an empty destructor to make
itk::FixedArray closer to being POD. This led to a better memory
alignment and improved the performance of some of our code by a factor
2:
http://www.itk.org/mailman/private/insight-developers/2008-June/010444.html

Note that I am not the only one caring about this:
http://www.itk.org/pipermail/insight-users/2010-October/038525.html

Anyhow, we may want to improve the documentation of itk::FixedArray
with respect to that point.

My two cents,
Tom

>
> What would be the argument in favor of adding the
> default constructor ?
>
> (initialization ?,
> note that we don't know what T is, in advance...
> I'm not sure that we can provide a reasonable
> initialization anyways.  T could be a std::string,
> or a highly complex class...)
>
>
>      Luis
>
>
> ------------------------------------------------------------------------
> 2010/11/16 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>
>>
>> Hi,
>>
>> Is there a reason to have the basic array types itk::Index and
>> itk::Offset, and maybe others, not implemented as a subclass of
>> itk::FixedArray?
>> Also, I see in the doc that no constructor are provided for performance
>> reasons. Is it still true with the compilers supported by itk 4?
>>
>> Thanks,
>>
>> Gaëtan
>>
>>
>> --
>> Gaëtan Lehmann
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>> http://voxel.jouy.inra.fr  http://www.itk.org
>> http://www.mandriva.org  http://www.bepo.fr
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>


More information about the Insight-developers mailing list