From: Steven H. <snh...@gm...> - 2007-09-27 11:54:59
|
On Thu, 27 Sep 2007, Nicholas Oxh=F8j wrote: > I find it really hard to find out how to map arrays of structs in C to > Perl arrays in a "natural" way. I think I have read all available > documentation AND searched mailing lists and the web for a solution - so > far to no avail. And it seems to me that I MUST be missing something > obvious, since this must be such a common requirement when mapping APIs > with SWIG... > > Sporadically I have found evidence of some kind of magic by adding > __getitem__ and __setitem__ functions to the shadow/proxy class allowing > you to do stuff like This probably won't help you much in the context of SWIG, but in the cases= =20 where multiple levels of set/get item methods are too cumbersome I=20 generally roll my own bindings in pure XS and build, e.g. arrays of=20 anonymous hashes directly in C. There's generally no magic way to form=20 these. You would need to gain familiarity with Perl internals. See: man perlembed man perlguts man perlxs man perlxstut for starters. It's also possible that Inline supports this, but I have no= =20 experience with it. SWIG does a super job of hitting a useful common denominator across all=20 languages, but you're getting into an area where it could benefit from=20 more "smarts". If the documentation on authoring SWIG language=20 personalities was more complete (or comprehensible) I'd take a crack at it= =20 myself. As it is, the learning curve is too steep. I don't have time to=20 reverse engineer a dense, undocumented system of C++ code and macros. There's a lot of information there, but despite numerous re-readings, I'm= =20 just not seeing a cohesive picture. Any time I've needed a capability=20 that was not intrinsic it generally entails an afternoon of swearing,=20 hairpulling and painstaking examination of the generated wrapper code.=20 There have been times I've simply given up and resorted to sed or perl=20 post processing to fix bindings dynamically after SWIG generates them. I continue to harp on these points because of my respect for what SWIG=20 does well. If I didn't think the application was worthwhile, I wouldn't=20 bother with it at all. It's just incredibly frustrating to have a=20 facility that provides about 80-90% of the functionality I need, but where= =20 implementation of the last 10% has such a high barrier. Steve --=20 |