You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current weak reference is class, when we use it, we must alloc slots from short or long weak reference table. Thus we can't use too many weak references. But I think this is not necessary. When GC happens, CLR can update strong references of living objects after compaction, why not update weak references of freed objects to be null at the same time? So weak reference can be a language feature instead of class, for example, use keyword "weakref" to specify a variable to store weak reference of an object.
Example:
Class A
{
weakref int[] a;
weakref object b;
};
The text was updated successfully, but these errors were encountered:
@ygc369 Language features like this should be made against the roslyn repo. There may be some runtime support needed here, but that work would coincide with a language spec update.
System.Runtime.InteropServices.GCHandle is unsafe low-level weak reference type that avoids the problem with extra allocation that you are pointing out.
The feature request to create a first class syntax for it should go into Roslyn repo as @kangaroo pointed out. There is actually a very similar one already - focused on event handlers: dotnet/roslyn#101
Current weak reference is class, when we use it, we must alloc slots from short or long weak reference table. Thus we can't use too many weak references. But I think this is not necessary. When GC happens, CLR can update strong references of living objects after compaction, why not update weak references of freed objects to be null at the same time? So weak reference can be a language feature instead of class, for example, use keyword "weakref" to specify a variable to store weak reference of an object.
Example:
Class A
{
weakref int[] a;
weakref object b;
};
The text was updated successfully, but these errors were encountered: