* Duncan Mac-Vicar Prett <dmacvicar@suse.de> [Dec 21. 2007 11:22]:
Huh ? I don't understand the part of wrapping in Ruby code. Have a look at the current satsolver.i file and the examples in ruby/tests. I think its pretty straightforward. Adding C++ classes seems more complex to me. But I'm open to any counterexamples ... :-P
C++ classes have been always there! since my first version.
%extend Pool { Pool() { return pool_create(); } ~Pool() { pool_free($self); }
That adds methods to the C struct. So SWIG is not parsing a C struct anymore but a C++ class. That is why the ruby pool class has member functions, constructors etc, otherwise you would get a plain C struct in Ruby (unless we wrap/extend them in pure ruby code).
Ahh, now I get it. Well, as you can see from the current .i file, this also works just fine with C. Actually, I stumbled over this too on my first tries yesterday. Then I learned about the difference between wrapper code (copied to the output wrapper) and interface description (parsed by swig to learn how to generate the wrapper). So the above Pool 'constructor' and 'destructor' are in fact not(!) C++ but the interface description for SWIG how to allocate and free instances of 'Pool'.
Where I am wrong is that even if SWIG is parsing C++, the output extension can be plain C I guess. I am not sure.
Just look at the currnet satsolver.i file. It has lots of %nodefault to suppress swig autogenerated alloc/free bindings. Instead, you can see pseudo-C++ to teach swig about instance allocation/deallocation. And its all pure C ;-) Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org