Buenas Michael D. Adams, el 23 de jun de 2006, a las 10:19 escribiste: > 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:
Note maybe we dont need the inheritance information to be preserved in the scripting language in all cases. > * 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? Does not seem to need the constructor (it will anyways wrap the ones from the class its actually wrapping). About the destructor i added it as otherwise the generated code would try to call the destructor which is protected, and cry about it, adding it into the interface seems to instruct swig to not try to call it directly. > * 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. > The interface file is just for generating the bindings, seems it uses c/c++ as its definition format for bindings, so it just needs a representation of what functions it can call in the class. This is what makes it possible to use .h files as swig interface files (when i realized this is when i thought about this solution), but its not required, swig author says he prefers separate .i files himself with the interface definitions. This way, for each .h file in cs we usually #include (through #include crystalspace.h) and %include it into the generated wrappers, the first include serves for compilation, the second serves to generate the wrapper code. > * (Minor) We don't inherit virtually from the template parameters. We > just use regular inheritance. (Virtual inheritance only comes into > play with iBase.) Indeed, removing the virtual part from the inheritance also works. > * 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. Yes, i plan to investigate this, just wanted to know if this was a good solution before elaborating further on it. thx a lot for commenting :) Pablo > 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] 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]
