core.runtime.GC memory alignment

Manu turkeyman at gmail.com
Sun Oct 27 19:21:42 PDT 2013


On 28 October 2013 06:50, monarch_dodra <monarchdodra at gmail.com> 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
>>
>
> In that case, we also need to specify how alignOf works. For example:
>
> struct S
> {
>     align(128) int i;
> }
>
> static assert(S.alignOf == 128);
>
> 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 had a lot of informal conversations with Walter trying to get my head
around the details here.
To my recollection, the intent was that it should behave like C, and that
S.alignof must certainly == 128 in that case. It can't work otherwise.
Alignment must be inherited by parent structures.

I also recall commenting on that case with ulong. On most architectures it
only needs to be 4 byte aligned, but that one is arch specific.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131028/a3a5f072/attachment.html>


More information about the Digitalmars-d mailing list