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

[Bill Lorensen]

The Borland test is crashing after an exception is thrown. I have a
fix I'm testing now.

Bill

On Mon, Jun 9, 2008 at 5:29 AM, Niels Dekker <niels-xtk at xs4all.nl> wrote:
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>