Excerpts from the mail message of Vivek Dasmohapatra:
)
)
) Oops - justy found this postponed message: looks complete-ish, can't see why
) it was postponed, so:
)
) On Thu, 27 Sep 2001, Billy Patton wrote:
)
) > I have an xs file that I have doing stuff.
) > Some is to search in my c database (home grown for data, unique to TI)
) >
) > I believe that there is too much crunching going on in the xs that needs
) > to
)
) IMO, a good approach is to have separate .c or .cpp files containing
) your 'real' functions, and have the XS layer be as thin as possible an
) interface between your perl and your C. The XS functions should really just
) be the interface declaration bit, plus a little argument fiddling as
) necessary to get from a list of perl arguments to something your C/C++
) can use. Plus any extra fiddling required to get the results back into a
) form perl will be happy with. (Extending the stack, etc).
I agree except that I find that it helps to make the XS code even
smaller by adding a thin layer in the module's *.pm file that
transforms arguments from Perl-friendly to C-friendly and back
again.
If I have C++ code that wants a big list of numbers, than I'll
write the XS code to expect a C-style array and I'll call the XS
code from a thin Perl wrapper sub in the *.pm file:
sub generate {
my $array= pack "d*", @_;
xs_generate( $array );
return unpack "d*", $array;
}
Tye
