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).