On 6/23/06, Pablo <[EMAIL PROTECTED]> wrote: > hi! > > I think many are aware of a problem we have with current scf and swig. > As swig does not correctly recognize the scfImplementation macros the > hierachy is not preserved in the scripting language, ie you cant use a > csPath where an iPath is expected. > > It is related to this warnings in the interface generation: > > <snippet> > ./include/cstool/collider.h:77: Warning(401): Nothing known about base > class > 'scfImplementationExt1<csColliderWrapper,csObject,scfFakeInterface<csColliderWrapper > > >'. Ignored. > ./include/cstool/collider.h:77: Warning(401): Maybe you forgot to > instantiate > 'scfImplementationExt1<csColliderWrapper,csObject,scfFakeInterface<csColliderWrapper > > >' using %template. > </snippet> > > The problem is the templates are generated in a way its difficult for > swig to understand, so using the %template directive results in swig > saying the template is not defined. I also tried including the necessary > files from scf but swig doesnt get it. > > It seems the solution is to use a separate interface file for the scf > templates. I have tried the following: > > http://delcorp.org/~caedes/sfc.i > (including it after %include "csutil/scf.h" in cspace.i) > > And it works, seems to provide enough info to swig. > Then the %template directive can be used as follows: > > %template(scfImageBase) scfImplementation1<csImageBase, iImage>; > %template(scfImageMemory) scfImplementationExt0<csImageMemory, csImageBase>; > > Seems to work well (tested on python), but as i'm not a swig, scf or c++ guru > I believe it might not be the most elegant solution, so i'd like to hear > comments or corrections from more experienced people (my apologies if my > solution is horrible). Also to me it seems awkward to have to use %template > for each class, maybe a better solution can be found (i'll look into this).
Overall this seems to be a good solution. It would be nice to eliminate the need for %template, but that doesn't bother me too much (we'll just have to remember to add it every time a class is converted to the new SCF or a class changes its interfaces). I do have a few questions/comments: * Why doesn't your scfImplementation1 declaration include a constructor declaration? Is it unneeded by swig? If so then why does swig need the destructor declaration? * Would this header be just for generating the C++ code for the bindings and the real header (scf_implementation.h) be used for compiling the C++ code generated by the bindings? If so then this trick will be ok, otherwise there are memory layout differences from the real header that may cause problems: - Technically speaking scfImplementation1 only includes QueryInterface. It inherits the other functions from scfImplementation. That might mean that the swig bindings expect an incorrect VTable. * (Minor) We don't inherit virtually from the template parameters. We just use regular inheritance. (Virtual inheritance only comes into play with iBase.) * Since you probably want to have scfImplementation2, scfImplementation3 and so on, maybe you could abstract this into a macro that you call multiple times. Unless maybe that confuses SWIG. In that case we might be able to abstract out most of the body into a common base class kind of like the real SCF does with scfImplementation so at little as possible has to be copied. Michael D. Adams [EMAIL PROTECTED] Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
