Hi Paul,

Thanks for the information.  It becomes clear to me now.  Yes, when I
mentioned "malloc and its derivatives", it means some other functions that
may provide extra security for guarding against out-of-memory (basically
some wrapper function around malloc), but which has nothing to do with
garbage collector.  Because my current objective is to be able to run with
GC.disable, then indeed I don't need ALLOC.

To me, writing Ruby C extension has been a very rewarding
experience.  Yes, Ruby is very elegant, and C is very powerful.  When we
combine these two, wow, it becomes a much more powerful combination,
because there are things that we cannot do easily in Ruby alone (such as
having a pointer, as in my previous question), and there are things
that we cannot do easily with standard C library alone (such as
dynamic creation of user-defined objects).

The critical junction, however, to me is the Data_Make_Struct/Data_Wrap_Struct
and the understanding on the consequence of having a garbage collector in
C programming, which is really something new.  Once we master this, I
guess everything else is just minor detail.

Regards,

Bill
==========================================================================
Paul Brannan <pbrannan / atdesk.com> wrote:
> If you ignore the out-of-memory situation, then there is no need to use
> ALLOC.  The point of ALLOC is that a) you may want to free memory
> periodically and b) if you are out of memory, malloc will fail and ALLOC
> will not.  If this is not a problem for you, or if you need to do your
> own memory allocation that does not involve malloc, then do not use
> ALLOC.

> Some of us do have to worry about out-of-memory situations.  For these
> cases, ALLOC makes perfect sense.

> I have other code that uses operator new to allocate memory for objects
> in Ruby extensions.  In C++, this makes perfect sense.

> Use whichever method of allocation makes sense in your application.

> Paul