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

[Mathieu Coursolle]

Hi ITK Developers,

I just tried to build ITK in 64 bits (x86_64 and ppc64) and ran into  
itkFixedArrayTest2 that was just added.

Part of the code goes like this:

   ArrayType * vec = new ArrayType[nelements+8];

   // Fill it up with zeros
   memset(vec,0,(nelements+8)*sizeof(ArrayType));


   // Display the alignment of the array
   std::cout << "Initial alignment: " << (((int)vec)& 7) << "\n";

As I built 64 bits,  vec is a 64 bits pointer. Trying to cast it as an  
int, which is 32 bits, cause a compiler error
on my machine (intel mac).

Is there some type like uintptr_t that could be use, which will be 32  
bits when built as 32, and 64 bits when built as 64?

Thanks.

Mathieu


On 6-Jun-08, at 1:38 PM, Niels Dekker wrote:

> Bill Lorensen wrote:
>> OK, I am way out of my league here, but the difference may be the way
>> POD ("Plain old Data") types and non-POD types handle memory
>> allocation.
>>
>> See:
>> http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/ 
>> POD.html
>>
>> It may be, that by having a destructor, the class becomes a non-POD
>> class. Without it, it may be a POD class.
>
> It may be... but FixedArray still has a user-defined copy assignment  
> operator, so "officially" it still wouldn't be a POD.
>
> My impression so far is that GCC interprets the presence of a user- 
> defined destructor in a very GCC-specific way...  It shouldn't / 
> necessarily/ change the way things are aligned.
>
>
>> Perhaps Brad King can shed some light on this. These questions are  
>> NOT
>> out of his league.
>
>
> Kind regards, Niels
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>

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