On 28 October 2013 06:50, monarch_dodra <monarchdo...@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.
