Cleaned up C++

[via Digitalmars-d]

On Wednesday, 22 April 2015 at 22:26:45 UTC, John Colvin wrote:
> On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim 
> Grøstad wrote:
>> On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
>>> Is it even possible to contrive a case where
>>> 1) The default initialisation stores are technically dead and
>>> 2) Modern compilers can't tell they are dead and elide them 
>>> and
>>> 3) Doing the initialisation has a significant performance 
>>> impact?
>>>
>>> The boring example is "extra code causes instruction cache 
>>> misses".
>>
>> Allocation of large arrays.
>
> That doesn't really answer the question without some more 
> context.

I think it does.

Compilers cannot tell what goes on because they cannot figure out 
nontrivial loop invariants without guidance. You need something 
like a theorem prover (coq?)...

Compilers may not be about to tell arrays won't be touched 
because of memory barriers when calling external functions, so 
they have to complete initialization before that. Presumably a 
Rust compiler could do better...

>Can you give a specific example where all 3 points are
> satisfied?

Not sure why you would need it, plenty of cases where compilers 
will fail. E.g. queues between threads (like real time threads) 
where you allocate in one thread and fill out data in another 
thread.

Any preallocation done on large data structures or frequently 
reinitialized data structures may perform better without explicit 
initialization.

For a system level language I think it would be better to verify 
that you don't use noninitialized memory using a theorem prover 
(sanitizer) or to use guards (like NaN). Automatic initialization 
is also a source of bugs.