On 14 Apr 2003, Steve Hart wrote:
> Sorry, should have said it was very useful (as far as it went :-). My
> point was that if you wrap an object using Data_Wrap_Struct the object
> returned resides on the stack - fine. If the object goes out of scope
> then GC deletes it. No?

No, but see below. If you view it from the C side, Ruby objects are never
created on the stack. What may be on the stack are just pointers to the
ruby objects:

  VALUE i_am_a_pointer_to_a_ruby_object;

Only VALUE-s for __ true, false, nil, __  and all Fixnum instances do not 
point anywhere, since they do directly and sufficiently encode an object.

So as long as there is a VALUE pointing to your object on the C stack, 
your object will not be deleted.

Your concern might be that your object will be deleted when the VALUE 
pointing to it goes out of scope, because the function that put it on the 
stack returns.

If no other accessible ruby object knows about your object by then, then 
yes, it will be deleted by the GC eventually. But see: This is what should 
happen. Why would you want the object to stay in memory if you have no 
means of accessing it anyway?

> The only way to prevent GC from deleting it would be to save the
> object in some system allocated memory AND tell GC using either
> rb_gc_register_address or rb_global_variable.

No. This is wrong. It is sufficient if your object remains accessible.
(btw the two functions are synonyms, and there is never a necessity to use 
one of them in an extension)

Ok, if you like working with global variables better, you can do it this 
way. Put a 
    static VALUE My_Object_For_Doing_My_Stuff;
in your C source file, register it as a global after initialization and 
reference it from your extension functions.

But realize that this is unnecessary. And it limits you to just one 
instance of Objects_Doing_My_Stuff. Why don't you simply implement your 
extension functions as instance methods of Objects_Doing_My_Stuff, and 
access your ruby object and the struct that it contains via the "self" 
parameter to these methods? Your object would not go out of scope as long 
as it is being used.

> Anyway, my only point really was that the GCAndExtensions could be
> expanded into the tutorial simon is writing. No criticism intended.

The critique was implicit, and _welcome_: Since you did not understand
how to cooperate with the GC after reading it, that text did not do its
job well enough, and has to be improved.

  Tobias