SWIG: returning a bool reference or pointer to Ruby


#1

I’ve got a class that defines the following method:

class AEdge {

virtual bool intersect( bool & overlap,
		    xyT & ix,
		    xyT & iy,
		    xyT & iix,
		    xyT & iiy,
			    const AEdge & ae );


}; //AEdge.h

Where overlap,ix,iy,iix and iiy are really values that should be returned
by the function. So in Ruby I’d like to be able to do:

intersection,overlap,ix,iy,iix,iiy = e.intersect(e1)
(where intersection is the true/false value which is the bool returned
from intersect).

I tried to do the following in the .i file to no avail:

%module Shapes
%include "typemaps.i"
bool AEdge::intersect(bool &OUTPUT,xyT &OUTPUT,xyT &OUTPUT,
xyT &OUTPUT,xyT &OUTPUT,AEdge&);

It kind of seems to me that I’m expecting a bit too much magic here but
that’s similar to what was shown in the latest SWIG/Ruby doc.

I also tried:

%module Shapes
%include “typemaps.i”
%apply bool OUTPUT { bool overlap };
%apply int OUTPUT { xyT ix, xyT* iy, xyT* iix, xyT* iiy };

but that didn’t work either (NOTE: I tried both references and pointers
thinking that SWIG converts references to pointers so maybe I need to do
that too).

Can someone clarify how this is supposed to work?

BTW: I checked the typemaps.i file for Ruby and found no mappings from
bool* to Ruby’s TrueClass or FalseClass, so maybe that’s the problem, but
I’m not sure how to achieve this mapping. I suspect this would be a lot
easier if Ruby had a Bool type that could be either true or false. I
think it’s been mentioned before, but it does seem a bit awkward that a
variable set to true is of type TrueClass and a variable set to false is
of FalseClass.

So how would one go about mapping from a bool on the C side to either a
true or false on the Ruby side and visa-versa?

Phil


(Lyle Johnson) #2

Can someone clarify how this is supposed to work?

For what it’s worth, I had answered Phil privately on this question
before I saw that he’d asked here also. The basic answer is to use a
combination of “argout” and “ignore” typemaps to tell SWIG that those
arguments should be wrapped as output values.

BTW: I checked the typemaps.i file for Ruby and found no mappings from
bool* to Ruby’s TrueClass or FalseClass, so maybe that’s the problem, but
I’m not sure how to achieve this mapping. I suspect this would be a lot
easier if Ruby had a Bool type that could be either true or false. I
think it’s been mentioned before, but it does seem a bit awkward that a
variable set to true is of type TrueClass and a variable set to false is
of FalseClass.

So how would one go about mapping from a bool on the C side to either a
true or false on the Ruby side and visa-versa?

Actually, for the most part this is already covered automatically by
SWIG. You just managed to hit on a special case that wasn’t covered
automatically (recognizing boolean values that are output by reference
in C++). In SWIG 1.3.12, you can already use the bool type in most
situations, e.g. for these declarations:

 void func_taking_a_bool_input(bool in);
 bool func_returning_a_bool_result();

you’d end up with Ruby functions that accept (or return) Ruby true and
false values.


#3

In article 3D0A02CA.2040503@users.sourceforge.net,

Can someone clarify how this is supposed to work?

For what it’s worth, I had answered Phil privately on this question
before I saw that he’d asked here also. The basic answer is to use a
combination of “argout” and “ignore” typemaps to tell SWIG that those
arguments should be wrapped as output values.

Thanks Lyle, your soulution worked.

For those interested in unit testing of C++ classes:

I’m working on a contract at a large company (everyone would know the
company if I named it, but I won’t for now) and we’re developing a C++
class library. We have a need to do unit testing (I’ve managed
to convince them that we do need to have some unit tests) of these
classes.

I tried CppUnit and after a couple of hours of playing with it couldn’t
get it to work. Then I decided to wrap the C++ classes with Swig and use
Ruby’s Test::Unit unit testing framework - I managed to get the first couple
of classes 'swig’ged and tested them out in Ruby in about 30 minutes (the
guy I’m working for on this contract was favorably impressed). So far
it’s working great (especially since Lyle’s suggested typemaps). I’m
impressed with the latest Swig (1.3.12). We have an abstract base class
that acts as a factory for concrete subclasses - I thought this would be a
major headache to wrap with SWIG, but there was no problem at all.

…Now back to ‘swigging’ more classes :wink:

Phil

···

Lyle Johnson lyle@users.sourceforge.net wrote: