I recently noticed that most (all?) RhinoCommon geometry objects implement IDisposable. I haven’t run across any sample code that creates new geometry objects without adding them to a document (which is presumably then responsible for their lifetimes), but if we’re creating intermediate geometry objects, should we dispose of them properly? I’ve never seen the question mentioned in documentation.
More on the IDisposable interface.
https://msdn.microsoft.com/en-us/library/system.idisposable.aspx?f=255&MSPPError=-2147217396
The primary use of this interface is to release unmanaged resources. Much of RhinoCommon is just wrappers around unmanaged (C++) objects found in core Rhino.
Does this help?
When you add geometry to the document, it is duplicated to avoid giving outside developers access to data inside the Rhino document. So in that case IDisposable isn’t really relevant, because it doesn’t concern the same instances of the classes.
Officially you’re always supposed to call Dispose() on an instance which implements IDisposable when you are done with it. However we realise that you don’t always know when you’re done with it, perhaps because pointers to the same instance may be shared all over the place.
If you do not (or cannot) properly dispose of an instance, it will (probably) eventually be handed over to the tender administrations of the garbage collector, which will finalize the object, and (hopefully) also free any unmanaged resources. This is typically not that big an issue with RhinoCommon classes, as they are allowed to fill up the memory. It is vital one disposes in time of GDI resources, as any application which uses more than X of them will be shut down by windows.
@stevebaer, please review for correctness.
I understand what IDisposable is for. I’m wondering why RhinoCommon doesn’t use it in an idiomatic way. For example, the example code in the documentation for Mesh.CreateFromBrep never disposes of the returned Meshes, even though they’re not added to the document. I can understand not disposing document geometry; I don’t understand why no other geometry is ever disposed of, either.
e: “We just let the finalizers take care of it because adding complexity to the documentation would do more harm than good” is the answer I was pretty much expecting, if that’s all that’s going on.
David’s reply is correct. If you want to be a very responsible developer, then it is good to call Dispose and free the geometry unmanaged resources when you are done with a class. Most of the time this really doesn’t matter too much since the finalizers will do this at some point in the future.
The downside of trying to be a very responsible developer is that you need to make absolutely 100% sure that the object can be disposed and will not at any point be accessed again. Doing so will lead to a DocumentCollectedException. I have removed many .Dispose() statements from code where I would think that it was OK to dispose the object, when it came back to haunt me later.
One tip to using disposable objects: if you enclose them in a using statement they will be disposed when the using scope ends:
using(Mesh m = GenerateTempMesh())
{
// do something with the mesh
}
// the mesh will be disposed automatically
1 Like