On Thu, Jan 05, 2012 at 07:38:24AM -0000, [email protected] wrote: > URL: http://svn.apache.org/viewvc?rev=1227512&view=rev > Log: > Added CFCHierarchy_allocate in order to play nice within > the ruby object allocation patterns. Updated CFCHierarchy_new to > call this function instead when creating the base CFCHIERARCHY_META > struct.
Summarizing and continuing an IRC discussion: The example code in the pickaxe book's appendix on the Ruby's C API (free download linked off of <http://pragprog.com/book/ruby3/programming-ruby-1-9>) for defining a class requires both an allocation function and an initialization function. We have the initialization function already: CFCHierarchy* CFCHierarchy_init(CFCHierarchy *self, const char *source, const char *dest); However, before this commit, we did not have an allocation function which met Ruby's needs: * Take no arguments. * Return a "blank" object. (Essentially, something suitable for running through the initialization function.) We have CFCHierarchy_new(), but it takes arguments and returns a complete object. CFCHierarchy* CFCHierarchy_new(const char *source, const char *dest); Here the new allocator: CFCHierarchy* CFCHierarchy_allocate(); I understand the need for zero-argument constructors e.g. when deserializing, though I don't completely understand whether the allocator is an absolute requirement for defining a Ruby class extension or just a quirk of the example code. If it's a requirement, we'll presumably be modifying Lucy's classes eventually and adding allocators there to accommodate Ruby. Marvin Humphrey
