Size of a class instance at compile time

[Don Clugston]

Daniel Keep wrote:
> Don Clugston wrote:
>> Daniel Keep wrote:
>>> I *think* that's right.  In any case, it's reporting the correct size 
>>> for every test case I throw at it.  Anything else that needs fixing? :P
>>
>>
>> One other nasty case is where the last member of a class is an 80-bit 
>> real, with padding that is different between Windows, Linux32, and 
>> Linux64. Does that work correctly?
> 
> Well, I tried sticking a real into the test cases in various spots, and 
> it seemed fine.  That said, I'm not sure what the potential problem is; 
> it currently determines the size of the member variables by finding the 
> maximum of (member.alignof+member.sizeof) for every member variable. 
> This means that, even if the last member is a real, that it will 
> correctly account for any padding *before* the real, as well as its' 
> full size.
> 
> Unless the compiler does really weird stuff like, for example, sticking 
> in padding after a real that isn't part of its' ".sizeof" on non Windows 
> platforms, I don't think it should be a problem.

That's exactly what I was worried about -- reals are followed by 0 bytes 
of padding on Windows, 2 on Linux32, and 6 on linux64. But it seems it 
is already included in sizeof; real.sizeof varies between platforms, 
even though the hardware is identical. real.alignof is constant for all 
of them.


> That said, if you DO find anything amiss, I'd love to know :)
> 
> That reminds me.  Walter: I know you're probably busy, but if you could 
> just give this the once-over to verify that it's counting the bytes 
> properly, that would be awesome.
> 
>     -- Daniel