> (The requirement being,
> of course, that [Counted] references can only be embedded in
> [Counted] objects or used on the stack.)
Would this exclude casting a [Counted] object to type System.Object?
Certainly System.Object would not be counted, so casting your MyCounted
object to System.Object would lose the reference counting.
Of course Dispose() can now be called even when there are outstanding
references to the object. I suppose that [Counted] references to your
MyCounted object would guarantee that the Dispose() did not get called
until all the [Counted] references went out of scope on the stack.
System.Object references to your MyCounted object could still be active,
but they would point to a disposed object after all the [Counted]
references went out of scope.
Implementation wise, the CLR would have to allocate space (on the heap)
where the ref count would be stored. Reference counting would have to be
thread safe. There would need to be a new IL instruction for assigning
[Counted] references (or at least every reference copy would have
examine metadata to determine the method by which to copy at JIT
compile.) Exception handling would have to take special care to
decrement reference counts as it unwound the stack. There are most
likely additional caveats that I have not thought of...
It would be a useful feature, but would be non-trivial to implement for
MS. It would also introduce under-documented determinism into the
system. One would have to look all the way back to the class definition
to find out if an object reference is [Counted]. Some local variables
going out of scope would have deterministic behavior and some would have
non-deterministic behavior: the behavior would not be obvious by just
reading the method code. (Compare with using(...) { } which has a self
documented place where deterministic disposing happens...)
--
Peter
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
