[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[SHOO]

(2010/11/03 2:47), Michel Fortin wrote:
>
> Le 2010-11-02 à 13:05, SHOO a écrit :
>
>>:
>>:
>>:
>>
>> Another viewpoint.
>>
>> Is SealedRange really appropriate?
>>
>> All these are caused by the same problem:
>> - http://ideone.com/x1Zus
>> - http://ideone.com/iM18Q
>> - http://ideone.com/TTin3
>> - http://ideone.com/x4b0o
>>
>> We should consider that we grope the common solution for these problems.
>> It is the method that block the access to reference data of which instance was deleted.
>
> In first and second examples, you're taking the address of a local variable. This is forbidden in @safe code, so I consider this already solved.

I don't think so.
@safe code cannot forbid to bring out the address:
http://ideone.com/rMl5i

@safe only forbid pointer operation:
http://ideone.com/8nWRP

So, this problem does not show solution, yet.



> In the third example, you're coping the sealed range into "r", then "ary" goes out of scope and delete the memory block while keeping a sealed range pointing to it. My take is that the implementation of Array is wrong: it should do *something* to either 1) prevent the sealed range from accessing the memory block, or 2) keep the memory block alive as long as a sealed range exists. Note that you can't write such an Array in @safe mode, and not using in @safe mode assumes you know what you're doing when it comes to handling memory. So I don't see that as a problem.

Even if my implementation is wrong, it is a problem that I can write 
such an implementation. I guess that the fundamental solution is not 
provided in SealedRange.



> As for fourth example, it uses scope classes, which will be deprecated in D2.

Yeah, this example is a main reason of the deprecation.
But, I think it is not necessary to make it deprecated if there is 
another method to avoid this. The method might dispense with SealedRange 
and solve problem copy construction cost.

Rather I am strong in interest about this problem.
I think that RAII is a main reason that a constructor and a copy 
constructor and a destructor were added to struct.
I suspect that it is the root of all evils that D cannot handle RAII well.



> Also take note that in second and third examples, the struct destructor is dangerous because it calls delete on a GC-allocated array "T[] a". As a general rule, you shouldn't access GC-allocated memory inside a destructor, this includes deleting it. That's because if you ever use this Array struct somewhere on the heap (like in a class), the GC could collect both the struct and the "T[] a" array at the same time, in whatever order, and you would calling the array's destructor twice (once by the GC + once in Array's destructor). But don't worry, you're not alone doing this mistake; I believe there is two instances of this in Phobos.

Ah... OK, you're right. It is not mentioned with the specifications (the 
point is mentioned by only class destructor specification), but I 
understand the thought.