Binary Serialization

[harakim]

On Sunday, 14 July 2019 at 00:18:02 UTC, Adam D. Ruppe wrote:
> On Saturday, 13 July 2019 at 23:52:38 UTC, harakim wrote:
>> class MoveCommand
>> {
>> 	byte serialNumber;
>> 	int x;
>> 	int y;
>> }
>> When I do MoveCommand.sizeof, it returns 4.
>
>
> It is important to understand a class in D is a reference type, 
> so `MoveCommand` here is actually a pointer internally, meaning 
> that 4 is the size of a pointer. Trying to directly read or 
> write that to a socket is a mistake.
>
> With struct though, there's potential. The reason you get 12 
> there though is that the byte is padded. The struct looks like
>
> 0: serialNumber
> 1: padding
> 2: padding
> 3: padding
> 4: x
> 5: x
> 6: x
> 7: x
> 8: y
> 9: y
> 10: y
> 11: y
>
>
> To get move the padding to the end, you can add `align(1):` 
> inside, so given:
>
> struct MoveCommand
> {
>   align(1):
>  	byte serialNumber;
> 	int x;
> 	int y;
> }
>
> The layout will look like this:
>
> 0: serialNumber
> 1: x
> 2: x
> 3: x
> 4: x
> 5: y
> 6: y
> 7: y
> 8: y
> 9: padding
> 10: padding
> 11: padding
>
>
> The align(1) is kinda like the __packed__ thing in C compilers. 
> The size of will still read 12 there, but you can read and 
> write an individual item direct off a binary thing reliably. 
> But an array of them will have that padding still. To get rid 
> of that, you put an align(1) on the *outside* of the struct:
>
> align(1) // this one added
> struct MoveCommand
> {
>   align(1): // in ADDITION to this one
>  	byte serialNumber;
> 	int x;
> 	int y;
> }
>
>
> And now the sizeof will read 9, with the padding cut off fromt 
> the end too. You can do an array of these now totally packed.
>
>
> This behavior is consistent across D compilers; it is defined 
> by the spec.
>
> Just remember types like `string` have a pointer embedded and 
> probably shouldn't be memcpyed!

Awesome. I kind of figured the D language would put this type of 
thing in the spec. Since the layout in memory will be consistent, 
I think I'm just going to let D do its normal thing and keep the 
members aligned in the default manner at a cost of a few extra 
bytes.

It's nice to know about align, though. In the unlikely event I 
end up running into this a lot, I will revisit that decision. I 
can just order my members for efficient space usage for now. As a 
side note, it would be cool if there were blank pages in the end 
of the The D Programming Language book to put addendums like this 
in there. I'll have to keep that in mind if I ever write a book.