Peter Stephens wrote: > > (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.
No, it wouldn't enclude casting to objects without the [Counted] attribute. References without the [Counted] attribute would be treated as 'uncounted' referenes, which don't contribute to the reference count. > 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. Right. > Implementation wise, the CLR would have to allocate space (on the > heap) where the ref count would be stored. Well, the CLR would simply add an integer representing a reference count to any class that is marked as [Counted]. > Reference counting would have to be thread safe. Yes. In the C++ world we do ref counting using InterlockedIncrement/Decrement. > 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.) You don't need new instructions, because, as you say, metadata is there and the JIT compiler can use it. > 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... Basically, the compiler would have to add try/catch blocks throughout the code. But that is far better than making programmers insert try/catch blocks when doing manual reference counting, as I'm doing now. As Agent Smith from The Matrix would say, "never send a human to do a machine's job." I don't think there are any other caveats - the C++ community has been doing this for a long time using reference counting smart pointers. > It would be a useful feature, but would be non-trivial to implement for MS. It's pretty trivial to do when compiling from a higher-level language to IL. It's somewhat harder when compiling IL to native code, but still not a big problem if the code is verifiable. It is rather hard to do in case of non-verifiable code. > 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]. No no no :). Marking a class as [Counted] would simply imbue a reference count and maybe some helper functions inside it. The references can be marked as both [Counted] and uncounted. Counted references contribute to the reference count. Uncounted (plain, normal) references don't, and this is a) necessary in order to avoid cyclic structures and b) significantly faster. Dejan www.jelovic.com You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
