From: Christian Boos <cboos@...>
Date: 2002-03-08T19:36:33+09:00
Subject: RE: Talking Trash About Ruby

My 2 cents on this�

> -----Original Message-----
> From: Sean Middleditch [mailto:elanthis@awesomeplay.com]
> Sent: Friday, March 08, 2002 6:09 AM
> To: ruby-talk ML
> Subject: Re: Talking Trash About Ruby
>
>
> On Thu, 2002-03-07 at 23:39, Lyle Johnson wrote:
> > All,
> >
>
> snip
>
> >
> > This is a big problem because the C++ object that this Data object
> > refers to has in fact been destroyed by this point, and so the Ruby Data
> > object has a "dangling" pointer. The code inside the mark function for
> > this class assumes that the object hasn't been destroyed yet; after all,
> > Ruby thinks it's still alive and so it must be OK. And we all know how
> > ugly things can get when you try to dereference a dangling pointer.
>
> How are these pointers getting freed?  The pointers should never ever be
> freed until the Ruby objects using them are freed.  You can use the C
> destructor function for Ruby objects to do this.
>
> If this isn't possible (i.e. you have to destroy the C++ objects at a
> certain time), then you should contain back pointers to the Ruby objects
> (to unset their pointer) or something similar, to ensure there is never
> a dangling pointer.
>
> Your method is relying on the idea that the Ruby objects will be out of
> scope.  This cannot be guaranteed, ever, since the programmer might make
> some weird references to objects in their code.  And Ruby code should
> never ever have the ability to crash the interpreter/host
> app/extensions.
>

Agreed.

You can have a working example of those ideas at:

http://www.bct-portal.com/opensource/ruby/regenerator/cpp.html

-- Christian