[Insight-developers] Empty FixedArray destructor: Performancehit using gcc (times 2)

[Niels Dekker]

Tom Vercauteren wrote:
> Thanks all for the very interesting discussion and especially to Brad
> for providing an explanation!

FWIW, the C++ FAQ Lite also has an item this issue:
http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-38.7 
"[38.7] How do compilers use "over-allocation" to remember the number of 
elements in an allocated array?"  Apparently GCC uses the so-called 
"over-allocation" technique.

> I guess that unless we find a solution to the explicit instantiation
> issue, we'll have to find another way to handle things.

I really hope the explicit instantiation issue can be solved!  Isn't it 
just a matter of doing a clean rebuild of itkCommon?  Otherwise we would 
be forced to /always/ provide a user defined destructor, for any class, 
right?

> Changing the implementation of ImportImageContainer::AllocateElements
> could be a way to go.

Which wouldn't be an easy way, I'm afraid.  The approach that I 
suggested, replacing new [] by malloc, might work, but it isn't very 
elegant.  A more elegant approach would be to use std::vector<TElement> 
internally.  The data buffer of an std::vector is contiguously stored in 
memory, so itk::Image could still use a raw pointer to the first 
std::vector element, to access all image data.  And I guess GCC will 
take care of aligning the data of std::vector efficiently.

> As far as the itkFastMarchingExtensionImageFilterTest is concerned,
> this seems to be a Borland only problem...

ITK supports Borland, so...


Kind regards,

Niels