in reply to Mixing C and perl

Instead of accessing the hash through a method on the Perl side, you can just use it as the perl wrapper for the C object.

You will have to store the C pointer inside the hash, for instance as $hash{__c_ptr}. Another option is to use <c>~ magic to save it, that way it will be invisible from the Perl side.

Replies are listed 'Best First'.
Re^2: Mixing C and perl
by jpl (Monk) on Jan 17, 2012 at 18:51 UTC
    I want to be able to get directly to the XS methods using
    $amd->method();
    If $amd is just a blessed hash reference, I think I'd have to "indirect through" the perl wrapper:
    # In AddrMatch.pm sub method { my $self = shift; my $Cptr = $self->{__c_ptr}; return $Cptr->xs_method(); }
    Also not too onerous. But will h2xs do all the right stuff to do the dynamic linking? I confess to considerable uncertainty about how the linking is made to work. I have tested the original model, and it appears to be doing the right thing with linking and reference counts.

      In the Perl-hash-wraps-C-struct setup, an object looks like {foo => 'bar', ... '__cptr' => \2131231231}. Well, with- or without the scalar reference to the number-that-is-a-pointer

      What you can do to make the XS methods work appropriately on this construct while being able to store stuff regularly from Perl as well, is to define a typemap that will a) check it got a hashref b) check that the class inherits from your package, c) fetch the __cptr slot of your hash-object, d) check it's a scalar ref, e) use the integer as a pointer, f) cast that into your C type. b), d), e), f) are done in T_PTROBJ already. This would allow you to write XS like with T_PTROBJ. The only downside is that you'd lose the ability to access the outer hash from XS.

        The only downside is that you'd lose the ability to access the outer hash from XSM

        Not really, just keep a pointer to the wrapping hash also inside the C structure, as in the OP sample code.