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?
