I'm not familiar enough with XS and SWIG to give a comparison, but I feel compelled to say something as no one else has yet responded. My brief excursions into both XS and Inline have convinced me never to touch XS unless I have to. Inline is easy to use and is constantly being developed and improved (the mailing list is rather active and Brian Ingerson is doing some interesting stuff with it). I do know that Inline must use the same compiler that compiled your Perl, so that may be an issue on Win32 systems, but that may also be the case with XS and SWIG, I just don't know.

To see how easy Inline is to use, you can check out my node The Ovidian Transform. I was fairly impressed how easy it was to come up with that code (note: that code was for playing around. A Guttman-Rossler Transform (sp?) or similar "all Perl" method would probably be a better choice).

In the meantime, you might want to check out the Inline mailing list. Many of the people there have used XS and SWIG, in addition to Inline, and would likely be able to answer some questions for you.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Where you run into the interesting parts is when you deal with perl's API, and that's the same no matter which scheme you use. The only thing that Inline and SWIG do differently is how they wrap the function parameters and return values. Inline has a few interesting ways to dynamically generate the function body itself, but for static functions there's no real difference.

Writing extension code in C is really no big deal. People seem terrified about it, but that's just stupid. It's only C after all--it's a computer language. It's not going to eat you or lurk under your bed waiting to steal your soul or anything. (Not like you're programming in lisp here)

You may ultimately not like C. That's fine. And you may end up cursing the state of the API and all its half-documented quirks. That's fine too.

Just don't be afraid of it. It's only ones and zeroes after all...

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.

-derby

There are a few good books on the subject. Advandced Perl Programming (O'Reilly) covers how to use SWIG and XS both, and some of the trade-off's betwix them. Extending and Embedding Perl (Manning) gives a more in-depth treating of how to effectivly use the tools. Neither of these give a good comparrison with Inline::C.

I expect the next sentance is going to get me in rough with the other monks ... I, personally, don't like Inline::C. Inline::C takes the C code you provide, and compiles it in a sub directory, and then uses that. While this is sometimes fine, machines without compilers (Productions Unix hosts, or Win32 machines) do not work with this. With Inline::C there is a speed penalty the first time (when it compiles), but it reuses the compiled version thereafter. Inline::C is quick to write, but i don't think that makes it better. I suggest reading the perlxstut and desiding for yourself which is best suited for your skill level and needs.

While this is sometimes fine, machines without compilers (Productions Unix hosts, or Win32 machines) do not work with this. With Inline::C there is a speed penalty the first time (when it compiles)

You can do an XS style install (compile once, distribute) with Inline, check the faq

-derby

If you do a search on perlmonks for cdrom, I have the same code as inline C. You can look at them for comparison.

The advantage to using swig is that it precompiles the c into a .so shared object file, thereby increasing speed. Inline c needs to compile the code at each calling of the script.