Extending and Embedding Perl

habit forming writes "Enjoy using Perl? Ever marvel at how Perl can "do the right thing" but still be written in C? Extending and Embedding Perl aims to take the black magic out of understanding our favorite language. In fact, the authors flat out admit they think it is unfair that only so few of us get to have one foot in Perl and one in C. Tim Jenness and Simon Cozens attempt to break down that barrier with lots of annotated code examples, direct analogies from the structures in Perl to those in C, a fine-grain look at XS and what it takes to robustly use a Perl interpreter in C."

Extending and Embedding Perl
author	Tim Jenness and Simon Cozens
pages	375
publisher	Manning (http://www.manning.com/)
rating	8.7 out of 10
reviewer	habit forming
ISBN	1930110820
summary	Get in touch with the inner Perl.

What's that up your sleeve?

It is my experience that many situations require us to "look under the hood" of (thoroughly examine) a solution to understand how to best use it effectively. Perl is no exception. The ability to bring such a force as Perl to a project at the proper time is a valuable skill to possess. However, wading chest-deep into XS and the Perl internals is not for the faint of heart. Jenness and Cozens ease this process by stepping in lightly at first.

What's in it?

The book begins with simple C examples that are then related back to the readers' knowledge of Perl. Then the text seems to throw us a curve by leaping off into building Perl modules. But there is method to the madness: building Perl modules correctly is inextricably linked to XS. Light introductions to XS are performed and the reader is well on his/her way to building .so extensions to any .pm.

After building a very specific foundation of simple C examples, module building, and some XS, the text returns to C to introduce pointers, arrays, file I/O and memory management. With these new skills, we begin to explore the structure and implementation of Perl variable types. Chapter 4 provides many useful diagrams of how Perl variables "look" and what C structures they translate into.

Still following a logical and constant order, we explore the Perl 5 API, learning how to post and retrieve information to the variable types explored in the previous chapter. As much as it might seem, this is not a rehash of the perlapi doc. It is consistent with the perlapi doc, but Jenness and Cozens provide extensively annotated C code examples.

Casting deeper still, we add the advanced C of pointers, arrays, file I/O and memory management to our knowledge of XS. At this point we have everything we need to effectively extend Perl, but the text continues deeper still by exploring how XSUB interfaces to Perl's internals. It is only the clearly documented, step-by-step explanations of this chapter that make it manageable for an average user like myself. Chapter 7 ends our stint with XS by discussing some alternative XS (or equivalent code) generation suites.

Switching gears entirely, we grab libperl.a and stuff into a C program. Chapter 8 begins the task of embedding Perl into a C program. Jenness and Cozens continue the embedded discussion through a Case Study in Chapter 9 and end with a look through the Perl internals in Chapter 10.

The final chapter (Chapter 11) details some of Perl's history, its development process, how we could become involved and what the future of Perl and Perl 6 may entail.

Final Thought

This book was indispensable in gaining a good foothold on using Perl in, from, and around C. I found it a good reference guide as well as an easy ,linear read. It is not a replacement for the perlguts, perlapi and perlxs documentation, but then again, it doesn't try to be. The annotated code examples with every line explained make following the book with development of your own solution a lot easier than in some other books. However, the in-depth explanations can be a bit frustrating for the impatient.

---

You can purchase Extending and Embedding Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Perl 5 API???

[mustangdavis]

"Still following a logical and constant order, we explore the Perl 5 API, learning how to post and retrieve information to the variable types explored in the previous chapter."

Isn't Perl 6 coming out soon?

Maybe the author should have held off releasing this book ... he might have been able to make more $$$ selling a Perl 6 book rather than another Perl 5 book (since every good programmer has a half dozen Perl 5 books anyways)

Re:Perl is Perl, C is C

[NerdSlayer]

If you want to complete a project in Perl, then just do it in Perl. If you want to use C for a project, just use C. It's bad enough when people start using buggy bloated libraries, but it's worse when they give their compiler an identity crisis.

I've done this on serveral occasions... did you ever have a huge project to finish in a small amount of time that had some sort of processor-critical portion that's run alot? Well then, I would suggest writing it in Perl and then optimizing that piece in C. Works for me.

Often in the "real world" you can't have your cake and eat it, too. That's why people embed C in Perl.

Re:Perl 5 API???

[thelenm]

Isn't Perl 6 coming out soon?

We all hope so, but it's not necessarily going to be released even in the next year or two. In the meantime, Perl 5 is more widely used than ever. And even after Perl 6 does come out, it will take a long time for people to switch over, assuming they do decide to switch. Heck, there's still a lot of Perl 4 code out there even though Perl 5 has been out for... like 8 years?

Re:Perl is Perl, C is C

[shoppa]

If you want to complete a project in Perl, then just do it in Perl. If you want to use C for a project, just use C.

But many projects need both low-level access to X/graphics/system libraries and really do benefit from the high-level approach of Perl.

In many cases, there are already libraries available that link the two together (e.g. Perl/Tk if you're writing in Perl, or associative array libraries for use from C) but it's never been a secret that you can call C code from Perl. You seem to advocate keeping it a secret.

Re:Perl is Perl, C is C

[iamwoodyjones]

Well what you could do is use PERL for checking/retrieving data properly and easily through a web page with less of a risk of buffer overflows since PERL has some great extensions to help in this process compared to another language such as C but then use another language such as C to pass that data (once it's been checked) so that the data's interpretation could be done exubrantly fast.

It's all about the right tool for the right part of the job.

Re:Combining C and Perl

[Scotch Game]

I know this is a joke, but it's a play on a concept I think it's time to reject, at least in part.

Far too much has been made of Perl readability. Yawn. Recently I opened up some code I wrote four years ago for a rather obscure application that I hadn't looked at since. After a minute, and only about a minute, I understood it perfectly. Granted, I wrote it, but similarly I rarely have problems reading other programmers' Perl code, if it's well written or at least well written enough.

Poorly written code is hard to read in any language, but Perl isn't very difficult. Sure, there's the odd regular expression that's difficult to decipher, but overall it's how well you know the language in question.

It just frequently seems that the readability issue seems to be centered around how well the code can be read by readers not only new to the code but new to the language as well.

For that matter, far too much has been made of Python's readability. I'll grant that Python isn't difficult to read, but I've seen some pretty goofy Python code, as well as Perl. Python, or any language for that matter, can be nicely obfuscated just by naming variables poorly.

And as far as memory protection in C is concerned, well, it's no worse than assembly, and C is smokin' fast when written properly.

In short, you want to go fast, then you're going to be driving Indycar and it's going to be risky for the amateurs. You want safe? Try Java, and buy a Prius.