As for this matter, the direct relations seem to be surely thin in
SealedRange as you say. However, I think that there is relation for the
situation that SealedRange is needed and the lifetime of data closely.
It reduces a use opportunity of SealedRange to make the situation that
cannot access dead data.
I think that copy constructor and move are not regarded as important in
the situation that can expose reference data without worry of to access
the dead data.
--
SHOO
(2010/11/03 3:08), Steve Schveighoffer wrote:
All of these have nothing to do with sealed ranges. They have to do with data
lifetime. If you destroy data and then try to access it, you will have problems
with or without sealed ranges. In addition, only one instance you show has a
sealed range in it. The rest either don't have ranges or are not sealed.
Having a sealed range does not necessarily mean that the user cannot shoot
themselves in the foot and delete the data while still maintaining references to
it. This problem is mostly solved by having the data or at least the pointer to
the data on the heap, destroyed by the GC when no longer needed.
Even then, this does not rule out the user calling clear on the pointer.
SealedRange is not a magic bullet for memory issues, and all these issues exist
with or without sealed ranges or expensive copy construction.
What SealedRange *does* do is allow the container to have complete control over
the storage for the data. This means it can:
a) intercept all accesses to the memory, including writes and reads.
b) use abstracted allocation schemes.
-Steve
----- Original Message ----
From: SHOO<[email protected]>
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.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
