[ODE] Re: ODE Digest, Vol 8, Issue 33

[Matthew D. Hancher]

> - Add a field to the class that dJointID points to, so it can remember 
> it's dJoint, if any.  But then people using the C API have to pay a 
> memory cost for something they don't use.  We could use the User Data 
> field for this (do Joints have them, or just geoms?), but then the user 
> can't use that field.

Yes, Joints and Bodys have user data fields as well as Geoms.  This is
exactly the approach that I currently take in my java wrapper library:
the user data field of each ODE object points to the corresponding
java object, and the java objects then have their *own* user data
fields which are what the user sees from the java API.  The same thing
would work trivially in C++, at the cost of one pointer per C++
object, without impacting C users at all.  On the other hand this does
also prevent users from combining the C and C++ APIs in some ways, so
I can certainly understand why you don't want to do it if that's a 
priority for you.

> As for dMass
> ...
> it's better as a struct than a class.  The dSetMassXXX() functions
> are just convenience wrappers, they don't belong as member functions.

I certainly agree that the data members of dMass should be public; I
think the second point is ultimately an aesthetic one.  I would
argue that operations such as mass translation, rotation, and
arithmetic also belong as member functions, though I probably use
those much more than the average person.

I guess the upshot of all this is that only real purpose of the C++
API (at least as currently envisioned) is to provide somewhat better
compile-time type-checking and somewhat cleaner code under some
circumstances at essentially zero cost in terms of memory footprint
and programmer hours.  This is perfectly reasonable; it just happens
not to be what I want.

(My work involves integrating a larger simulation library, of which
ODE is just one piece, and I am not interested in having my library's
API suffer for historical reasons related to one particular component.
For instance I have no intention of exporting the ODE C API at all, so
those issues are irrelevant to me.  I had been hoping that I could use
the ODE C++ API as a starting point for the ODE component of mine, but
it looks like our goals are different enough that I shouldn't bother.)

In any event I will add the few currently-missing core features to the 
ODE C++ API and send along some source next week after I've had a 
chance to test it.

mdh

Matt Hancher
NASA Ames Research Center
Official: mdh at email.arc.nasa.gov
Personal: mdh at media.mit.edu