Tye McQueen wrote:
> Then there is the solution of:
>
> * Have the XS code wrap an object around the buffer.
>
> That is what T_PTROBJ is about. I personally hate this option
> [if you want to create an object, do it in Perl code]. So I'd
> never consider it unless the library won't allow me to allocate
> the buffer.
>
> ) The example in perlxs confuses me when I get to the part about
> ) "Netconfig *T_PTROBJ". What is this?
>
> I don't think this is completely documented. It is about the
> only support in XS that can kind of handle buffers that are not
> allocated by Perl. You stuff a pointer to the buffer into an SV
> and bless it [making a Perl object] and then write XS routines
> that act as methods for this object.
Do you know of any examples of this that I can crib from? In the past
I've wanted to 'ghost' a perl tree-of-hashes on top of an underlying C
'tree-of-linked-lists'. I did this by hiding a pointer to the C structs
inside the perl hashes using the appropriate kind of magic, and then
using TIEHASH magic will all the tie methods implemented in XSUB to
populate the perl tree-of-hashes from the appropriate bits of C data
structure as the perl tree was traversed. The reason for doing this is
that in most cases only a tiny subset of the C data structure is
actually accessed, and copying the entire thing into perl would have
been unacceptably slow. This worked extremely well, but is overkill for
most cases. For the next chunk I'm writing all the memory management is
done by the C library, so I could use the simpler T_PTROBJ stuff, but a
'real life' example would be most helpful.
Alan Burlison
