Why does ode provide a C interface instead of a c++ one

[bach...@gmail.com]

Hi all,
I've read that ode was programmed in C++, but why doesn't it provide a
c++ interface,?it will be really practicle.

[Rodrigo Hernandez]

It doesn't?

I though odecpp.h was it.

[Daniel Price]

I love C++ but C has some big advantages (some off this is explained
in the ODE manual). For one thing, C is better supported by most
compilers than C++ and because C is the lowest common denominator, it
means you can build other frameworks on top - there are other language
bindings for ODE.

But the biggest reason is that a C interface is simpler and more
flexible. You don't have to learn a class hierarchy to use it and you
don't have to worry about the complications that c++ presents, like
memory managed, hidden operations etc of said classes. Just use the
core functions you need and go from there. There's nothing to stop you
wrapping those function calls with your own classes as I have done.
And you will learn a lot more in the process.

[Daniel Price]

Wait...what?!

[bach...@gmail.com]

// intentionally undefined, don't use these in very class odecpp.h :(

[Daniel Price]

OK this is why ODE fails in the documentation department. Unless I'm
missing something, there is no mention of an public C++ interface. It
seems I've spent months duplicating the very same thing. Argh!

On 12 Dec 2008, at 19:02, Rodrigo Hernandez wrote:

>

[bach...@gmail.com]

there is no existing c++ warp for ode actually?

[Remi Ricard]

Hi,

> OK this is why ODE fails in the documentation department. Unless I'm
> missing something, there is no mention of an public C++ interface. It
> seems I've spent months duplicating the very same thing. Argh!
>

This can be your first contribution to ODE to add this documentation.

Remi

[Daniel Price]

That comment refers to the copy and assignment operators which don't
make sense in those cases (see why C is simpler?)

[Rodrigo Hernandez]

I don't use the wrapper myself, but looking at it, it seams to mean
don't use copy constructors, not don't use the classes, last update to
the header was 4 days ago, so should be current enough.

[Daniel Price]

The docs have not been updated since 2006...I wouldn't know where to
begin.

Just looking at this file, there is no wrapper for spaces or geoms?

[Daniel K. O.]

Daniel Price escreveu:

> The docs have not been updated since 2006...I wouldn't know where to
> begin.

There are 2 official docs: the headers themselves have doxygen docs, and
the wiki. The wiki says right in the manual's introduction page:

"Has a C++ interface built on top of the C one."

> Just looking at this file, there is no wrapper for spaces or geoms?

Yes, there is. Look further, in odecpp_collision.h.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

[Daniel Price]

On 12 Dec 2008, at 19:50, Daniel K. O. wrote:

Daniel Price escreveu:

The docs have not been updated since 2006...I wouldn't know where to  

begin.

There are 2 official docs: the headers themselves have doxygen docs, and

Are the doxygen documents complete? The last time I looked they were only partial. As for official documents, are you referring to the one on ode.org (under the _latest_ user guide link), the one in the google groups file directory or the one on the wiki (http://opende.sourceforge.net/mediawiki-1.6.10/index.php/Manual) ?

the wiki. The wiki says right in the manual's introduction page:

"Has a C++ interface built on top of the C one."

Yes I see that now but it's not emphasized (there is a section detailing why the API is written in C for example) and there is no mention of odecpp.h or odecpp_collision.

I had seen the internal cpp classes and assumed it was referring to those

Just looking at this file, there is no wrapper for spaces or geoms?

Yes, there is. Look further, in odecpp_collision.h.

Well at least I know about this now!

[bach...@gmail.com]

Daniel Price a écrit :

so why don't you use a singleton class?
or at least make them private ;)

[bach...@gmail.com]

and what does:
/* C++ interface for non-collision stuff */
mean?

[bach...@gmail.com]

ok i understood, collision stuf are in odecode_collision.h

[bach...@gmail.com]

On Dec 12, 8:09 pm, "bachir...@gmail.com" <bachir...@gmail.com> wrote:

OK i understood after i've benn looking at odecpp_collisions.h

[Mikko Rasa]

While it does not make sense to copy the object, it does make sense to
have multiple worlds or bodies. So singleton is out of the question.

> or at least make them private ;)

They are private. They are right at the beginning of the class, and the
default member protection is private.

--
Mikko Rasa "The DataBeaver"
FlipOut: http://www.tdb.fi/flipout.shtml

[Mikko Rasa]

Daniel Price wrote:
> But the biggest reason is that a C interface is simpler and more
> flexible. You don't have to learn a class hierarchy to use it

There is a class hierarchy to learn, even though it isn't supported on
the language level. Hinge, Universal and Contact are all Joints; Box,
Sphere and Capsule are all Geoms. The C and C++ interfaces mirror
themselves in this.

> and you
> don't have to worry about the complications that c++ presents, like
> memory managed,

Generally you have to worry about memory management more in C. In C++
you can put objects in stack, or use smart pointers to make freeing them
automatic. Building a C++ interface as a wrapper on top of the C one
allows for certain pitfalls though, such as the C object going away
while the C++ one still lives. Also exceptions can't be used through
any functions compiled in C mode (not that ODE uses any).

> hidden operations etc of said classes.

This can be a problem if the library or interface has been designed in
such a way that there are surprising operations. However, it is easy to
work around this wiht good design.