Ian Upright <
[hidden email]> wrote on comp.lang.smalltalk:
>I can see it as a definite disadvantage, if all you are doing is simply
>making straight C calls and SWIG is not generating any interesting C or
>Smalltalk code for you at all. Even for pure wrappering, SWIG does generate
>some handy code that DLLCC doesn't, like providing additional support for
>booleans, null terminated strings, etc. It is more flexible in controling
>the names of the methods, instead of just (myfunc:with:with:with) etc..
>Also, using typemaps for more exotic and complex cases is obviously
>impossible with DLLCC.
>
>If you're using SWIG to generate accessors for structures, accessing C++
>code, etc.. you need to generate a wrapper. If you're not doing this, it
>seems to be a deficiency with SWIG in general. It would be interesting if
>we could detect or control this situation, and in this case somehow emit
>code that binds directly to the target C library instead of generating a
>wrapper, where it's not needed/required. I don't think anybody has
>extended/hacked SWIG to do this for any language, but I think it might be
>doable.
Just a further comment on this, for anyone who is interested.. I had a look
at the SWIG Smalltalk module, and while it's unconventional in the SWIG
world, it looks like I can add a feature, whereby instead of creating a
wrapper for the C function, it just directly maps to that function instead.
It doesn't seem like it should be too hard, and does make a whole lot of
sense.
Obviously, this would require some care with it's use, but for wrapping pure
C functions (and not C++ or accessors for structures, variables, constants,
etc.), it could get rid of the need to generate a C wrapper at all. (And in
many cases, it would just provide an alternative for the parsing
functionality that DLLCC provides) This would work, but users would have to
stay within a certain limited subset of functionality. (but no worse than
say, what DLLCC provides)
I'll add that as a feature request and hopefully integrate it into the next
build, and that should work accross all Smalltalk dialects. I imagine I'll
have to add some support to declare the calling convention that is desired,
as one would need to specify that and get it right in using this particular
feature.
Ian
---
http://www.upright.net/ian/
Locked
