Compiler could elide many more postblit constructor calls

TommiT tommitissari at hotmail.com
Sun Jun 30 01:34:19 PDT 2013


On Sunday, 30 June 2013 at 08:16:44 UTC, anonymous wrote:
> On Sunday, 30 June 2013 at 07:27:06 UTC, TommiT wrote:
>> 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
>>>>> }
> [...]
>>>
>>> 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
>
> 3) foo mutates the data through a mutable global.
>
> int[] data = [1, 2, 3];
> void foo(const S)
> {
>     data[0] = 42;
> }
> void main()
> {
>      const S s = S(data);
>      foo(s);
> }
>
> Pure functions can't access globals, so they're fine here.
>
> (I'm rather ignorant about that whole postblit thing, just 
> trying to clarify  Diggory's point as I understand it.)

If this is indeed Diggory's point, it's not very pointy (sorry). 
The compiler should be able to safely omit the postblit on 's' 
when it passes it to foo (and the possible destructor of foo's 
argument inside foo when foo exits).


More information about the Digitalmars-d mailing list