struct field alignment

[Robert Jacques]

On Sun, 17 Oct 2010 22:00:49 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> http://www.digitalmars.com/d/2.0/attribute.html#align
>
> Over time, it has become clear to me that there are only two useful  
> alignments:
>
>    align     // set to whatever the C ABI alignment is
>    align(1)  // pack everything in, no alignment padding
>
> I think any other alignments should be deprecated. Note that with  
> align(1), any alignment is achievable simply by adding in byte fields  
> where desired.

I mainly do GP-GPU work using NVIDIA's CUDA + D. Passing data into and out  
of the GPU requires conforming to align(8) and align(16) structs as well  
as structs that contain align(8)/align(16) structs. At first, I tried  
using align(8)/align(16) + .alignof, only to find out that those weren't  
supported. Currently, I use an enum flag and a bunch of packing/unpacking  
routines in order to send/access data. Maintaining the correct alignment  
with composite structs manually is a difficult/brittle endeavor; its fine  
for interfacing with a stable code base, but not for development where  
things are constantly changing. Also, CUDA requires that the programmer  
maintain the proper function call alignment, adding another place where  
one has to remember to pad correctly.

Although I have a solution that works well for me, the one thing I lament  
about not having a canonical D way of expression align(8)/align(16), even  
at only a meta-information level, is that if phobos gets a small vector  
library, I can't use it and conversely I'm not motivated to improve/submit  
my own small vector library to phobos.