core.runtime.GC memory alignment

[Peter Alexander]

On Sunday, 27 October 2013 at 21:20:12 UTC, John Colvin wrote:
> On Sunday, 27 October 2013 at 20:50:30 UTC, monarch_dodra wrote:
>> On Sunday, 27 October 2013 at 20:30:05 UTC, Andrei 
>> Alexandrescu wrote:
>>> Yah, something like that. I found align(NNN) underspecified 
>>> and underpowered for my work with allocators. As a simple 
>>> matter, NNN must be a literal, not a compile-time expression. 
>>> You can't even write e.g. align(size_t.alignof), which is 
>>> fairly basic.
>>>
>>>
>>> Andrei
>
>> "alignment relative to the start of the struct"
>
> what does that even mean? Alignment means (address % alignment) 
> == 0

Alignment also means alignment within an object. It's more 
commonly referred to as "padding" but it's a form of alignment.


> what would be the use case for guaranteeing ((fieldAddress - 
> StructAddress) % alignment) == 0 that can't be just as easily 
> done using normal alignment

Usually it's done when you are reading binary files that are in 
some particular format that may or may not pack data in the same 
way that you'd get from normal alignment.


> If "align(N)" is supposed to only mean "alignement relative to 
> the start of the struct", why the heck is S's "alignOf" 128?
>
> Also, (but I can't double check it right now), I seem to 
> remember that there are odd things, like "ulong.alignOf == 8", 
> yet if you declare one on the stack, you notice it's only 4 
> aligned (at least, on my win32 (I think) it is...)

I believe .alignof also refers to structure alignment, it doesn't 
guarantee alignment in memory or on the stack (as you've 
discovered).