[Kde-bindings] Re: [Kde-java] Re: GCJ (Re: Build system for KDE4)

[Richard Dale]

On Saturday 18 June 2005 09:21, Ashley Winters wrote:
> --- Simon Edwards <simon at simonzone.com> wrote:
> > On Saturday 18 June 2005 04:35, Ashley Winters wrote:
> > [Smoke and parsing C++ header and gcc stuff snipped]
> >
> > May I insert a dumb but related question, where does garbage
> > collection for
> > language like Python, Ruby etc fit into Smoke and all this?
> >
> > just curious,
>
> I was going to write out an even long answer than this, but short is
> probably better. :)
>
> Smoke lets the bindings hook into an object's virtual destructor. That
> way, they can know when the object gets deleted (window closed) by Qt,
> and act like it's holding smart pointers which go undefined when the
> object disappears.
You need to keep a mapping from the C++ instance to the corresponding instance 
in the bindings language. In qtruby the table looks like this:

QPtrDict<VALUE> pointer_map(2179);

The key is a pointer to a C++ instance, and the value is a ruby VALUE, which 
is how you refer to a ruby instance from C.

When you create a new instance you add an entry to this table. Then in the 
object's virtual destructor there is a callback to remove the instance from 
the table.

> Also, when an object leaves language scope, we call whatever passes for
> its parent() function to see if it's "owned" by another object. If so,
> we override the language's object destruction and hide the object in
> it's parent. That way, if the object ever shows up again, its state
> remains the sane. For example:
>
> sub foo {
>     my $m = new QMenuBar;
>     $m->{my_data} = "a value I want to keep";
>     setMenuBar($m);
> }   # $m is gone, but the menubar got stored in this
>
> sub someEvent {
>     # if we retrieve the menubar later, we get the original object
>     blurfl(menuBar()->{my_data});
> }
>
> If the object has no parent, the object will get deleted by the binding
> when all variables to it go out of scope and the language calls the
> finalizers. In Perl5, that's deterministic. For other languages, it
> happens whenever they feel like it.
I think python has a reference counting scheme like perl.

Ruby uses mark and sweep garbage collection. When you wrap a C++ pointer 
inside a ruby instance, you provide a function which gets called when there 
is a mark phase:

extern void smokeruby_mark(void * ptr);

So when smokeruby_mark() is called it can do checks such as finding out 
whether the instance still has a parent, and if so the instance can be marked 
as still being in use.

After the mark phase, any ruby instances which aren't marked are garbage 
collected.

-- Richard