I've written quite a bit of XS code and read even more XS code that other people have written.

This has convinced me that the best way to use XS is to avoid it as much as possible. By this I mean, if you can do something in Perl, then you probably should do it in Perl.

I see lots of XS code that tries to build an array, pull values out of a hash, create objects (bless), etc. These modules always end up doing a pretty poor job of this (as well as causing the authors lots of pains trying to get the code to work). For example, such code won't handle tied variables. Even worse, the APIs that result are always less flexible and less Perl-like and so are a pain to use.

And I've had the dubious task of trying to debug, patch, and enhance some of these modules. Doing that to "Perl written in C" really, really sucks. With most modules, I can use the Perl debugger to quickly find problems and then I can work around them easily, often without even modifying the module. With these heavy-XS modules, finding the bugs are much, much, much, much harder, I can rarely work around them when I find them, and usually have to recompile the XS code.

Much better is to have a Perl subroutine that does the Perlish things and puts the items in a format that is easy for C to make use of, and then have the XS only do things that are easy to do in C and hard to do in Perl.

And so I encourage you to use Inline::C since it is a wrapper for XS that encourages you to use only simple arguments which might get you to put more in your Perl and less in your C. It is also easier to use.

        - tye (pack "d*",@_)