Mailinglist Archive: zypp-devel (56 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx