From: Issac <issac@...>
Date: 2001-12-10T04:11:40+09:00
Subject: [ruby-talk:28037] Re: Boost.Ruby ?

> >>At the moment, these simple C structs, with their associated Ruby
> >>objects, are enough for my purposes, but it would be quite nice to allow
> >>a C++ object as the "shadow" of a Ruby object. It looks like
> >>Boost.Python would be a good source of ideas for this project.
> 
> 
> I'd be interested to see how the Boost.Python people pulled this off.
> I see that you already noticed that name mangling is *not* portable 
> between brands of compilers. Perhaps Boost assumes a GCC compatible 
> compiler?

I'm pretty sure Boost.Python supports various compilers, but I'd be surprised
if it could get two different C++ compilers to play nicely together on the same
project.

> This is a bit of a hack, but a useful intermediate step:
> You can have "extern c" statements (possibly called as a macro which 
> detects if the compiler is C, and does nothing, but is active for C++)
> C++ users would have to pass what they can of their /C++ class/, into a 
> /C struct/.

To extend Python with C++, it's a good idea to first compile the python 
interpreter with the C++ compiler with which you want to do your extending.  
I foolishly tried to do that with the ruby interpreter and got scads of error 
messages having to do with ruby's internal K&R-ness.  Maybe it would
be possible to get the ruby API to compile with a C++ compiler and leave
the rest as K&R, including the remaining headers as "extern C".  That ought
to make it possible to avoid the hack you mentioned.  Then again I am really
not sure if C++ is all that good of a language for directly writing extensions
since it forces its users to jump through all these ridiculous hoops.  It might
be better to just do it all through a well-defined ABI like CORBA or COM
or just bite the bullet and write some C.