[ODE] Ode.NET and space/geometry memory management

[Jason Perkins]

On 11/27/06, Andreas Fredriksson <deplinenoise at gmail.com> wrote:
> I hope you don't mind me emailing you directly. I found your address
> in the README of Ode.NET and I was unsure what mailing list you lurked
> on. Feel free to point me to such a list if you think it more appropriate.

Please use the ode-list, see http://q12.org/mailman/listinfo/ode


> When you create a space, or attach a body to a geometry, how should
> client code be structured to maintain the pointer graphs that exist
> within ODE under the IntPtrs the API hands back? It seems to me that
> working with raw IntPtrs would be a nightmare, and I can't think of a
> clean way to design a wrapper that understands all the various cleanup
> rules involved without mirroring the pointer graphs that ODE keeps
> internally.
>
> I think this is mainly an issue because geometries are useful on their
> own, so it makes sense to treat them as first-class objects. However,
> when you add them to a space the space will auto-destroy them and the
> handle becomes dangling. On the other hand, if you set space cleanup
> to zero and the geometry somehow references the space after its gone,
> that's another crash waiting to happen. Client code in .NET can't
> really see when a handle has been invalidated by some other operation
> within ODE itself.
>
> Do you think an elegant scheme for this could be invented?

This really isn't a .NET specific question. Even if you are using C,
trying to use a geom both inside and outside of a space, where one or
both could be released at any time, will require some custom
management code.

Jason