[ODE] odecpp.h

[Martin C. Martin]

Hey Henry,

As I submitted it, most classes have two constructors: the default
constructor, which has no arguments and sets the id to zero, and the
"real" constructor which takes arguments and initializes the object.  I
would have made the "real" constructor the only one, but then you couldn't
have arrays of most objects.  The down side is that the compiler can't
catch all cases of an object used before its initialized.

dSpace and dWorld have the nifty feature that they're "real" constructors
don't take any arguments.  So, I made the default constructors create a
space/world and didn't provide a "set id to zero" constructor.  Therefore,
you could create an array of them and they'd all be properly initialized. 
Also, it would be impossible to use one before initializing it.

Looks like Russ changed it.  But if he hasn't changed the destructor, you
need to change it to this:

~dSpace ()
 { if (_id) dSpaceDestroy(_id); }

> 2. A few functions take d*ID as parameters rather than objects. eg...
> 
>    void add (dGeomID x)
>      { dSpaceAdd (_id, x); }
> 
> It feels a bit nicer to me to do this...
> 
>    void add (dGeom x)
>      { dSpaceAdd (_id, x->id()); }
> 
> What do you think?

dGeoms will be automatically converted to dGeomID when needed.  So, you
can already do this:

// Space: the final frontier
dSpace my_space;

// Create the monolith
dBox monolith(1.0, 4.0, 9.0);

// Add the monolith to the space
my_space.add(monolith);


I think having the "operator dGeomID" in dGeom is a cleaner solution,
because it means less code to maintain (and therefore fewer chances for
bugs), and also allows dGeoms to be used in anybody else's code that takes
a dGeomID, even if they didn't think about the C++ wrappers.  The only
down side is that it's a little cryptic, as you pointed out.  Maybe time
for a comment in the odecpp.h and/or the docs?

- Martin