chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] [Swig-dev] Future of SWIG chicken module


From: John Lenz
Subject: Re: [Chicken-users] [Swig-dev] Future of SWIG chicken module
Date: Mon, 09 Feb 2004 19:58:16 -0600

Well, not quite - the type-checking for `foreign-...' is done on the
Scheme side.
But usually pointers are untyped, as you correctly point out. But
IIRC Jonah has used
a special undocumented feature of Chicken ("tagged pointers") for
that stuff.
But, as I said before, I haven't looked at the SWIG code too hard.

I saw that from reading through the SWIG code, but I could never find it in the documentation :) Why use tagged pointers? The way in which SWIG represents pointers is really wierd. Maybe Jonah can answer it better, but see below.


I think the current method is fine. The code generated by SWIG is not
necessarily less efficient, than what Chicken generates. There are some points where the current SWIG Chicken module could be improved, by supporting specific features (like constants, etc.). Also the type-checking of numeric arguments is not fully optimal (fixnums should be accepted for flonum arguments,
for example). And multiple values are (AFAIC) not handled.
But otherwise it works fine.

That is kinda the same conclusion I came too... there aren't many benifits. I will talk with Jonah now that he is back and I think we will proceed with SWIG viewing chicken the same as any other language. I kinda had the idea but then after thinking about it for a while, it is just too complicated. The way in which SWIG represents types might need to change a little, but other than that...

I still think it would be a cool thing tho to still call SWIG directly from chicken, although I don't know how well that would work. If chicken is asked to parse some header files, it could first look for SWIG and if found, it could run SWIG passing it the input file. SWIG would then still generate a seperate file containing all the wrapper functions which would output in the same directory as the rest of the files chicken was exporting. SWIG would then have to return all the . scm files that it created for chicken to continue processing. Maybe just have a seperate #>SWIG <# or something. There are still some problems with this tho which would need to be investigated...


----------------------------------------------------------------------
Well, the one big thing we need to fix is the type checking. The chicken SWIG module is completly broken... it will accept any type to any argument that takes a pointer. Secondly, it does the incorrect thing on multiple inheritance.

To see the problem with multiple inheritance, take a look at this example

(define-foreign-type foo (pointer "Foo"))
(define-foreign-type bar (pointer "Bar"))
(define-foreign-type joo (pointer "Joo"))

#>
 class Foo { public:  int a; };
 class Bar { public:  int b; };
 class Joo : public Foo, public Bar { public: int c; };

 Foo *newJoo() {
   Joo *j = new Joo();
   j->a = 1; j->b = 2; j->c = 3;
   return j;
 }

 int heya(Bar *b) { return b->b; }
<#

(define new-Joo (foreign-lambda joo "newJoo"))
(define heya (foreign-lambda int "heya" bar))

(display (heya (new-Joo)))

That should display 2 but it displays 1. The problem is, inside the class Joo, the Bar base class is not at the beginning of the memory assigned to Joo so when doing a direct cast from C_word to Bar *, the pointer is pointing at the Foo part of Joo. SWIG can automaticly detect this and will convert the pointer to the correct type, but again the SWIG chicken module currently does not.

This is what I reported as SWIG bug #782468
http://sourceforge.net/tracker/?func=detail&aid=782468&group_id=1645&atid=101645

John




reply via email to

[Prev in Thread] Current Thread [Next in Thread]