Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Wrapping a C Library: Allocation and duplication issues

Reply
Thread Tools

Wrapping a C Library: Allocation and duplication issues

 
 
Justin Bonnar
Guest
Posts: n/a
 
      09-13-2006
I'm writing a wrapper for a C library [1] written in a very object
orientated style. All of the "classes" are created with a
librdf_new_classname method which acts almost the same as Ruby's
Class#new.

The problem I'm having is cleanly separating allocation from
initialization. Since most of the class construction functions require
arguments to initialize the object, I can't define separate alloc and
initialize functions.

The only option I see is to use Ruby 1.6 style code and define a
Klass.new method for my classes. The problems with this is it prevents
clean subclassing and object cloning. Is there a better way to wrap the
library?

Thanks,
Justin

[1] http://librdf.org/

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Joel VanderWerf
Guest
Posts: n/a
 
      09-13-2006
Justin Bonnar wrote:
> I'm writing a wrapper for a C library [1] written in a very object
> orientated style. All of the "classes" are created with a
> librdf_new_classname method which acts almost the same as Ruby's
> Class#new.
>
> The problem I'm having is cleanly separating allocation from
> initialization. Since most of the class construction functions require
> arguments to initialize the object, I can't define separate alloc and
> initialize functions.
>
> The only option I see is to use Ruby 1.6 style code and define a
> Klass.new method for my classes. The problems with this is it prevents
> clean subclassing and object cloning. Is there a better way to wrap the
> library?
>
> Thanks,
> Justin
>
> [1] http://librdf.org/
>


What about calling librdf_new_classname() from the initialize method,
and not doing anything special in the alloc function?

README.EXT says:
> To define and undefine the `allocate' class method,
>
> void rb_define_alloc_func(VALUE klass, VALUE (*func)(VALUE klass));
> void rb_undef_alloc_func(VALUE klass);
>
> func have to take the klass as the argument and return a newly
> allocated instance. This instance should be empty as possible,
> without any expensive (including external) resources.


The ary_alloc function for Array, for example, does not allocate storage
for the actual C array of VALUE. It only allocates the basic RArray
object, with a null ptr. Then rb_ary_initialize() looks at the arguments
and allocates storage for ptr, as needed.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

 
Reply With Quote
 
 
 
 
Justin Bonnar
Guest
Posts: n/a
 
      09-13-2006
I don't think that approach will work: librdf_new_classname() allocates
the memory it needs and returns a pointer to the structure. Part of the
problem is that struct may be different depending on the arguments
passed in (a particular storage backend, etc) and that the C header
files don't define the internals of the structures themselves (so I get
incomplete type errors during compilation.

-Justin

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Justin Bonnar
Guest
Posts: n/a
 
      09-13-2006
Acutally, I'm not a C or Ruby/C guru, but would any of the following be
possible?

- Wrapping a null pointer in the allocation function, and then modifying
the DATA object to use the pointer returned by the
librdf_new_classname() call.

- Creating a pointer to the data structure, and then setting it's value
to the pointer returned by the librdf_new_classname() call.

The following code compiles and runs, but doesn't seem to work correctly
(other functions that access the C structure wrapped by the object
behave strangely.)

static VALUE URI_alloc(VALUE klass)
{
librdf_uri* uri;
return Data_Wrap_Struct(klass, 0, librdf_free_uri, uri);
}

static VALUE URI_initialize(VALUE self, VALUE uri_string)
{
librdf_uri* uri;
Data_Get_Struct(self, librdf_uri, uri);
uri = librdf_new_uri(World, StringValuePtr(uri_string));
return self;
}

Thanks,
Justin

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
ts
Guest
Posts: n/a
 
      09-13-2006
>>>>> "J" == Justin Bonnar <(E-Mail Removed)> writes:

J> The following code compiles and runs, but doesn't seem to work correctly
J> (other functions that access the C structure wrapped by the object
J> behave strangely.)

Look at ruby-1.8.5/ext/dbm/dbm.c, in the ruby source, to see an example
how you can do this (fdbm_alloc(), free_dbm() and fdbm_initialize())



Guy Decoux


 
Reply With Quote
 
Lyle Johnson
Guest
Posts: n/a
 
      09-13-2006
On 9/12/06, Justin Bonnar <(E-Mail Removed)> wrote:

> I'm writing a wrapper for a C library [1] written in a very object
> orientated style...


Just curious: Are the Ruby bindings that come with Redland just not
suitable for your project? I'm wondering why you're re-inventing the
wheel here.

 
Reply With Quote
 
Justin Bonnar
Guest
Posts: n/a
 
      09-13-2006
ts wrote:
> Look at ruby-1.8.5/ext/dbm/dbm.c, in the ruby source, to see an example
> how you can do this (fdbm_alloc(), free_dbm() and fdbm_initialize())


Thanks, this is exactly what I was looking to due.

Lyle Johnson wrote:
> Just curious: Are the Ruby bindings that come with Redland just not
> suitable for your project? I'm wondering why you're re-inventing the
> wheel here.


The RDF-Redland binding is outdated and decidedly un-ruby-like. The
other problem is the SWIG binding for Redland doesn't expose all of the
functions I wanted to access. In addition to wrapping Redland I need to
get at some of the lower level functions from Rasqal.

We're also planning on building an Ontology-aware level above Redland,
with goals similar to that of the (now-defunct) Semitar project and want
to get the lowerlevel code right before working on that. Mixing the
existing binding with higher-level C code would be a little ugly - we'd
prefer to keep the lower level code in C.

-Justin

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Lyle Johnson
Guest
Posts: n/a
 
      09-13-2006
On 9/13/06, Justin Bonnar <(E-Mail Removed)> wrote:

> The RDF-Redland binding is outdated and decidedly un-ruby-like. The
> other problem is the SWIG binding for Redland doesn't expose all of the
> functions I wanted to access. In addition to wrapping Redland I need to
> get at some of the lower level functions from Rasqal.
>
> We're also planning on building an Ontology-aware level above Redland,
> with goals similar to that of the (now-defunct) Semitar project and want
> to get the lowerlevel code right before working on that. Mixing the
> existing binding with higher-level C code would be a little ugly - we'd
> prefer to keep the lower level code in C.


Cool. I hope that you'll share when you're done.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
An idea for heap allocation at near stack allocation speed Bjarke Hammersholt Roune C++ 14 03-06-2011 08:07 AM
static memory allocation versus dynamic memory allocation Ken C Programming 24 11-30-2006 12:37 AM
Wrapping a C Library: Allocation and duplication issues jbonnar@gmail.com Ruby 0 09-11-2006 07:54 PM
What is the difference between dynamic memory allocation,and stack allocation ? chris C++ 6 10-28-2005 05:27 AM
how to build web application and avoid the same page sections duplication(header..) Grzegorz Stasica Java 2 02-12-2004 10:18 AM



Advertisments