[Top][All Lists]
[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