# The following was supposedly scribed by
# Mik Firestone
# on Thursday 29 July 2004 08:59 am:
> I have read the Cookbook, and I can get my code to work if
>I actually create a blessed reference. I would prefer to bless it - I just
>want a reference that I can later pass to other C functions.
>
>I have looked at the docs for Inline::Struct, and I do not think that is
> what I want. Again, I do not want a blessed reference, just a reference.
Okay, I'll take this second statement to mean that you omitted a 'not' from
the first.
I think you really do want to use Inline::Struct.
Do you want your code to be object-oriented? Is it okay if it is?
Do you want the struct's values accessible from perl?
Basically, your perl variable, whether it is blessed or not, is a pointer to
an SV or an RV. If your C functions are not compatible with the (SV* foo)
prototype, you are going to have trouble passing SV's to them. This means
that everything has to be wrapped with a pack/unpack layer.
Inline::Struct, without digging through the source, appears to wrap your C
functions, this means that if you do $obj = Inline::Struct::Foo->new, that
$obj is essentially the blessed reference to the scalar containing the integer
value of the pointer to the struct (as per the cookbook.)
The difference appears to be that myfunc() (from the Inline::Struct
documentation) is going to be wrapped with a function like:
void struct_myfunc(SV* obj) {
return ( myfunc( (Foo*)SvIV( SvRV(obj) ) );
}
Which means that myfunc has to expect a (Foo *f), rather than an SV*.
If you have a pile of existing C functions, Inline::Struct should wrap them
automatically.
But, if you just use Inline::C, it will wrap only those functions for which it
can determine a typemap. This won't work for structs, only for int, float,
char*, (see Inline::C manpage.)
Another note, regarding your code. Your Soldier is not getting free()d
anywhere. That's why the cookbook has a DESTROY function. This gets
automagically called when the object goes out-of-scope. With your code, the
C object is not blessed, so a C DESTROY function would not get called.
However, you could have perl DESTROY function which calls a C function to
free the $self->{obj}. I'm betting that this is where the segfault comes in
(try a sleep(5) at the very end of your code, if that delays the segfault, it
is a destruction issue.)
--Eric
