[gtk-list] Re: I want to understand

[andrew cogent ca]

Ionutz Borcoman writes:
 > Robert_Gasch/PeopleSoft@peoplesoft.com wrote:
 > > 
 > > 4) Using C++ as the base would make other language bindings more difficult
 > > to write (??)
 > C++ mangles names in the object code generated, while C not. I have
 > understood that this is the reason why bindings to C code is simpler to
 > made. Somebody please correct me if I'm wrong.

That's part of it.  Name mangling can also be a big problem for
dynamically loaded object code or dynamic shared libraries.

Generally, a C binding is "knowable".  You can look at the function
declaration and know how to make a call through a pointer-to-function
to it.  That is not so easy with C++.  Methods have a hidden "this"
which is not necessarily passed in a portable way, so your language
binding may need to be compiler-dependent.  One common way out of this
is to make C wrappers of C++ methods.  That stinks.

Optional arguments are more difficult to deal with in alternate
language bindings.

Overloaded functions are pretty near impossible to deal with in
alternate language bindings without making distinct function wrappers
for the overloaded functions.  Same goes for operator overloading.
Classes that implement interesting combinations of
public/private/friend are difficult to deal with if your target
language does not implement something similar.

So, if you plan to map a C++ API to an alternate, non-C++ language,
you pretty much have to "undo" everything that C++ does so you can get
to the underlying functionality.  C does not present this issue in
to nearly the same degree.  Even if you write your language
interpreter in C++, you will probably pray that the toolkit APIs that
you use are written in C.

Andrew