std.format and uninitialized elements in CTFE

kinke noone at nowhere.com
Thu Dec 5 21:50:39 UTC 2019


On Thursday, 5 December 2019 at 20:47:02 UTC, Steven 
Schveighoffer wrote:
> Well, as long as all members are void initialized, then it 
> should have an effect right? I know that the compiler blits the 
> whole struct at once, but if it's all void initialized, it 
> doesn't have to.

LDC and DMD still pre-initialize it (optimizer disabled) in that 
case (and druntime etc. via generic `= T.init` code). I doubt 
there's a good use case for a struct defining all of its fields 
as uninitialized, without being able to be sensibly 
default-constructed (no default ctor). These cases are probably 
better handled outside the struct, i.e., where the dangerous 
uninitialized allocation resides, and can be handled in some 
little factory function returning a void-initialized stack 
instance.

E.g., this attempt at manually eliminating the init blit/memset 
before the ctor call:

struct S {
     int[32] data = void;
     bool isDirty = void;
     this() @disable;
     this(const int[] data) {
         this.data[] = data[];
         isDirty = false;
     }
}

can be expressed (and actually works) like this, maintaining 
sensible default-constructability at the price of a somewhat more 
verbose `S.get()` for manually optimized construction:

struct S {
     int[32] data;
     bool isDirty;
     static S get(const int[] data) {
         S r = void;
         r.data[] = data[];
         r.isDirty = false;
         return r;
     }
}


More information about the Digitalmars-d mailing list