[ODE] Re: ODE c++ API

[Ed Jones]

For what it's worth, I'd like to see an updated C++ interface to ODE 
too. And I'm all for thin wrappers, the thinner the better.
Just off the top of my head, some of the things I think could be 
improved are;

- It would be better to have a consistent dVector equivalent class to 
pass to things like "void setGravity (dReal x, dReal y, dReal z)" and to 
be returned from things like "const dReal * getPosition() const" rather 
than passing three separate dReals and receiving a pointer to an 
internal structure.

- Likewise for dMass, dQuaternion, dMatrix3, etc

- The copy constructors and assignment operators should be implemented

- Trimesh stuff needs including (and the Plane2D joint, if that's going 
to be promoted to core)

- I'm not sure I like exposing the setData / getData, isn't that very 
C-stylee, can't you get the same effect (in a more OO way) by subclassing?

- If we could wrap the collision callback up in an interface like 
"dCollisionListener" or something that'd be cool.

- Stick everything in a namespace, "ode" for example.

Yes it's possible for everyone to write their own C++ wrappers (I've 
done it myself, a couple of times), or modify the existing one but as 
you say "it required a surprizing amount of tweaking to get it where I 
wanted" and surely it'd be better to have a single consistent wrapper 
rather any everybody writing their own?

Obviously all this is IMHO!

Cheers,
Ed.

P.S. I've had some issues with VC 2003 .NET and the dx structures, 
meaning you have to forward declare them (just as empty structs) in one 
of your project source files. Something to do with managed and unmanged 
code, or something else that I don't understand, maybe a "proper" C++ 
interface would fix this compatibility issue. Or maybe it's just me 
being stupid?


Martin C. Martin wrote:

> Alright, I resubscribed.
>
>> The current c++ wrappers function as a thin layer ontop of the C API,
>
> > which i think works well for c++ programmers.
>
> "Thin layer" just means that Russ did a good job with his object 
> oriented design, so that IDs that ODE returns corresponded to objects, 
> and function calls to methods.  That made the wrapper trivial to 
> implement, although it required a surprizing amount of tweaking to get 
> it where I wanted.  I suggest you do the same with Python.
>
> > But, for the purposes of making the python wrappers, they need to be 
> thicker,
>
>> and more object oriented.
>
>
> Hmm, why is this?  Just because "thin is trivial, so thicker is better"?
>
>> The big change i guess would be enclosing the dReals inside a new
>> vector or matrix object.
>
>
> I've never integrated C code into python, but can't it access a 
> contiguous set of floats as a vector or an array?  Doesn't it already 
> have types that do that?
>
>> If dxSpace is being used by a
>> class, then dxSpace must also be exposed to boost,
>
>
> I don't see why.  Can't Python manipulate dxSpace through an ID, the 
> way it presumably does with everything else?  You could store the 
> handle in the "user data" field.
>
> - Martin
>
>
>
> #################################################################
> #################################################################
> #################################################################
> #####
> #####
> #####
> #################################################################
> #################################################################
> #################################################################
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode