From: Eric N. <ni...@pa...> - 2006-11-09 21:46:28
|
William S Fulton wrote: > Eric Nickell wrote: > >> William S Fulton wrote: >> >>> Eric Nickell wrote: >>> >>> >>>> Following the example in the "SWIG and Java" section of the swig >>>> docs, I'm trying to add some basic functionality to all the >>>> swig-generated proxy classes. But for some of these proxy classes, I >>>> need to add other functionality as well. So I end up with something >>>> of the form: >>>> >>>> %typemap(javabase) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [], >>>> SWIGTYPE (CLASS::*) "SWIG" >>>> >>>> %typemap(javacode) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [], >>>> SWIGTYPE (CLASS::*) %{ >>>> protected long getPointer() { >>>> return swigCPtr; >>>> } >>>> %} >>>> >>>> %typemap(javacode) struct BananaPhoneInfo %{ >>>> public int hashCode() { >>>> return getPointer(); >>>> end >>>> %} >>>> >>>> >>>> Of course, this doesn't work, because the 2nd typemap(javacode) sets >>>> the typemap for the more narrowly defined match, occluding rather >>>> than augmenting the first typemap(javacode). >>>> >>>> Is there a means in the "typemap(javacode) struct BananaPhoneInfo" to >>>> have swig include the text of the wider match as well? >>>> >>>> >>>> >>> Yes this is a nuisance which I will resolve in a future release. For >>> now, the best thing is to use some macros to stitch together all the >>> bits that you want. Note that in order for the preprocessor to expand >>> your macros, you need to use {...} braces for the typemap and specify >>> noblock=1 to remove them, as the %{ ... %} braces are not processed by >>> the preprocessor, for example: >>> >>> %define GENERIC_EXTRA_CODE >>> protected long getPointer() { >>> return swigCPtr; >>> } >>> %enddef >>> >>> %typemap(javacode, noblock=1) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE >>> [], SWIGTYPE (CLASS::*) >>> { >>> GENERIC_EXTRA_CODE >>> } >>> >>> %typemap(javacode, noblock=1) struct BananaPhoneInfo { >>> GENERIC_EXTRA_CODE >>> public int hashCode() { >>> return getPointer(); >>> } >>> } >>> >>> But unfortunately you get some preprocessor comments in the generated >>> code. The other thing to try is: >>> >>> %typemap(javacode) SWIGTYPE, SWIGTYPE *, SWIGTYPE &, SWIGTYPE [], >>> SWIGTYPE (CLASS::*) >>> %{ >>> protected long getPointer() { >>> return swigCPtr; >>> } >>> %} >>> >>> %define ADD_HASH_CODE(CTYPE...) >>> %typemap(javacode) CTYPE %{ >>> protected long getPointer() { >>> return swigCPtr; >>> } >>> public int hashCode() { >>> return getPointer(); >>> } >>> %} >>> %enddef >>> >>> ADD_HASH_CODE(struct BananaPhoneInfo) >>> ADD_HASH_CODE(struct ApplePhoneInfo) >>> ADD_HASH_CODE(struct PearPhoneInfo) >>> ... etc. >>> >>> >>> William >>> >>> >> The 1st technique doesn't seem to work because of swig forcing insertion >> of a wrapping { } block, which is not allow for declaring methods as >> part of a class. >> >> Since most of the BananaPhone stuff is struct-specific %extends, it's >> probably just easier for now to replicate the boilerplate code into each >> one of those. >> >> > > The first technique does work as explained because of the noblock attribute. > > William > Missed that. Thanks. |