Thread overview
Big struct/class and T.init
Feb 19, 2023
Guillaume Piolat
Feb 19, 2023
Guillaume Piolat
February 19, 2023

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?

February 19, 2023

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

February 19, 2023

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:

struct S
{
    char[16384] array = 0; // no .init storage
}

-Steve

February 19, 2023

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:

struct S
{
    char[16384] array = 0; // no .init storage
}

-Steve

TIL. Nice trick!