(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.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
