Array init
Don
nospam at nospam.com
Tue Sep 1 06:21:38 PDT 2009
Max Samukha wrote:
> Steven Schveighoffer wrote:
>
>>> That's an interesting question. The compiler does set void-initialized
>>> member variables to zeros:
>>>
>>> struct S { double x = void, y = void; }
>>> void main() {
>>> S s; // x and y are initialized to 0
>>> }
>>>
>>> I think this is a bug. Such members should be left uninitialized or
>>> initialized to the default initializer for the type (NaN in this case) or
>>> void initialization should be disallowed for member variables.
>> An initialized double is NaN, so I don't think the compiler is
>> initializing those variables.
>>
>> Your test is not valid, you need to fill the memory with something to see
>> if the code doesn't change it.
>
> I should have posted the asm listing of the test case. The compiler does
> generate initialization code that sets the memory allocated for the
> structure to zeros, which defeats the purpose of void initializers.
>
>
> ...
> dd offset FLAT:_D4Test1S6__initZ at SYM32
> db 000h,000h,000h,000h,000h,000h,000h,000h
> db 000h,000h,000h,000h,000h,000h,000h,000h
> ...
> _Dmain:
> push EBP
> mov EBP,ESP
> sub ESP,010h
> push ESI
> push EDI
> mov ESI,offset FLAT:_D4Test1S6__initZ at SYM32
> lea EDI,-010h[EBP]
> movsd
> movsd
> movsd
> movsd
> xor EAX,EAX
> pop EDI
> pop ESI
> leave
> ret
> .text._Dmain ends
>
> I guess the rationale behind this behavior is that filling void-initialized
> fields with zeros may be as fast or faster than skipping them while
> selectively initializing other fields.
Yes, it would definitely be faster if everything else is initialized to
zero.
> IMO, the initialization code shouldn't be generated for aggregates that have
> all members void-initialized, and consequently for arrays of such
> aggregates.
Agreed. (But it's just a performance issue, it's not incorrect to
initialize them to zero).
More information about the Digitalmars-d-learn
mailing list