Re: Big struct/class and T.init
On Sunday, 19 February 2023 at 18:29:05 UTC, Steven Schveighoffer wrote: On 2/19/23 1:26 PM, Steven Schveighoffer wrote: Testing with run.dlang.io, switching between `char` and `int` changes the ASM output to show whether it's stored or not. And BTW, you can override this by assigning a zero default: ```d struct S { char[16384] array = 0; // no .init storage } ``` -Steve TIL. Nice trick!
Re: Big struct/class and T.init
On 2/19/23 1:26 PM, Steven Schveighoffer wrote: Testing with run.dlang.io, switching between `char` and `int` changes the ASM output to show whether it's stored or not. And BTW, you can override this by assigning a zero default: ```d struct S { char[16384] array = 0; // no .init storage } ``` -Steve
Re: Big struct/class and T.init
On 2/19/23 1:11 PM, Guillaume Piolat wrote: If my understanding is correct, the mere fact of having a: struct S { char[16384] array; } And then using it anywhere, will necessarily lead to a S.init being created and linked, leading to a binary size inflation of 16kb. This is not a super high concern, but can inform design decisions. Is this correct? Yes. that's not the case for all-zero .init though. At least in `TypeInfo.initializer`, it's pointing to null with array size indicating the amount of zeroes to write. Testing with run.dlang.io, switching between `char` and `int` changes the ASM output to show whether it's stored or not. -Steve
Big struct/class and T.init
If my understanding is correct, the mere fact of having a: struct S { char[16384] array; } And then using it anywhere, will necessarily lead to a S.init being created and linked, leading to a binary size inflation of 16kb. This is not a super high concern, but can inform design decisions. Is this correct?