Compiler could elide many more postblit constructor calls

TommiT tommitissari at hotmail.com
Sun Jun 30 00:27:05 PDT 2013


On Sunday, 30 June 2013 at 02:20:24 UTC, Diggory wrote:
> On Saturday, 29 June 2013 at 17:57:33 UTC, TommiT wrote:
>> On Saturday, 29 June 2013 at 13:47:36 UTC, TommiT wrote:
>>> [..]
>>>
>>> Example:
>>>
>>> ----
>>> struct S
>>> {
>>>   int[] values;
>>>
>>>   this(this)
>>>   {
>>>       values = values.dup;
>>>   }
>>> }
>>>
>>> void foo(const S) { }
>>>
>>> void main()
>>> {
>>>   const S s;
>>>   foo(s); // No need to call postblit
>>> }
>>
>> One important related detail:
>> If the compiler decides to elide the postblit of S on the call 
>> to foo(s), then the destructor of S (if S happened to have 
>> one) should not be called when the call to foo exits and the 
>> argument passed to foo goes out of scope. The logic behind 
>> this is that when we omit the postblit on the argument that's 
>> passed by value, it is as-if we had passed the argument by 
>> const reference (except that the argument is considered local 
>> to foo, i.e. not returnable by reference and what not).
>
> Unless the function is pure, this is only possible for 
> immutable parameters otherwise the original variable may be 
> modified while inside the function even if it is passed by 
> const.

I'm not sure I follow. Are you saying...
1) the function foo could cast away const and modify s
or
2) some other thread could modify s while foo is executing

case 1:
void foo(const S s)
{
     S m = cast(S) s;
     s.values[0] = 42;
}

I'm not sure how this is in D, but I think in C++, casting away 
const and then modifying the variable is potentially undefined 
behaviour. I think the compiler should be free to assume that the 
programmer hasn't written code that has undefined behaviour.

case 2:
I don't think another thread could be modifying s, because it's 
not shared, i.e. it's a thread local variable. If the parameter 
to foo was "shared const S", then it could be modified by another 
thread, and thus the postblit could not be elided.



More information about the Digitalmars-d mailing list