Ok.. NOW I understand. You're right. I was thinking "globally". In C#, static and "global" are practically synonymous.
You can get *similar* behavior to what you're talking about in C# a couple of different ways. Not exactly, mind you, but similar...
One way is to make sure that Entity, Vector3 and Quaternion are stack-bound objects (which means they have to exist as structs rather than classes). In .Net, the stack's memory is self managed and is not ever GC'ed. Once they are popped, they are gone in one swipe like you mentioned above. Of course, making those objects as structs will limit you in other ways, so this wouldn't be something you could realistically adopt in all circumstances.
Another method is to design your class so that it is GC'ed as efficiently as possible when it's finally destroyed.
To use your example (assuming Vector3 and Quaternion are classes with default constructors):
[Code]
public class Entity {
public Vector3 position = new Vector3();
public Quaternion rotation = new Quaternion();
}
[/code]
When Entity is created by the client code, the child objects Vector3 and Quaternion are created right away. This ensures the objects live next to each other in the heap which allows the GC to remove it in a singular chunk (rather than having to defragment the heap to find all the children that belong to a particular object)
Better yet, mix and match when you can to reduce reference-type objects. If possible, make Vector3 and Quaternion structs. They will be popped from the stack, and Entity will be a single reference to destroy upon GC.
You can get *similar* behavior to what you're talking about in C# a couple of different ways. Not exactly, mind you, but similar...
One way is to make sure that Entity, Vector3 and Quaternion are stack-bound objects (which means they have to exist as structs rather than classes). In .Net, the stack's memory is self managed and is not ever GC'ed. Once they are popped, they are gone in one swipe like you mentioned above. Of course, making those objects as structs will limit you in other ways, so this wouldn't be something you could realistically adopt in all circumstances.
Another method is to design your class so that it is GC'ed as efficiently as possible when it's finally destroyed.
To use your example (assuming Vector3 and Quaternion are classes with default constructors):
[Code]
public class Entity {
public Vector3 position = new Vector3();
public Quaternion rotation = new Quaternion();
}
[/code]
When Entity is created by the client code, the child objects Vector3 and Quaternion are created right away. This ensures the objects live next to each other in the heap which allows the GC to remove it in a singular chunk (rather than having to defragment the heap to find all the children that belong to a particular object)
Better yet, mix and match when you can to reduce reference-type objects. If possible, make Vector3 and Quaternion structs. They will be popped from the stack, and Entity will be a single reference to destroy upon GC.