12.2. Tips for the C Programmer

You no longer must declare all your variables at the beginning of a block before any executable code. In fact, declaring them as late as possible is good practice because it keeps statements that belong to the same functional element together.

Perl's scalar variables are not strongly typed. They can switch oyster-like between integers, floating point numbers, and strings according to your whim (although if you ever turn a reference into a string, you can't turn it back). Even when you assign an object of a specific class to one, nothing stops you from overwriting it with an object of another class or something that isn't even an object at all. Polymorphism at its best. There is (as of version 5.005) the capability to declare to the compiler that a scalar is an object belonging to a particular class (my Dog $spot), but even that is only a loose agreement that you can break any time you feel like it.^[2] (It allows for compile-time checking of accesses to fields, which are one way of implementing instance data.)

^[2] As of press time, Damian Conway had mooted a module which could restrict a variable to a particular object class, but not even the name had been agreed on.

Dynamic (i.e., nonlexical) variables have global scope unless qualified with a local statement. But you won't want to program in this BASIC style anyway; declare all variables as lexical, and the scoping rules are the same ones you're already used to.

Your days of wondering whether your frees match your mallocs are over! It is very hard to create a memory leak accidentally in Perl. Whenever you see code like this

$soldier = make_warrior ('squaddie'),
sub make_warrior
   {
   my $fighter;
   ...
   return $fighter;
   }

which would make your heart leap into your mouth in C, relax. In C terms, $fighter is being allocated from the heap, not from the stack, so it doesn't become vulnerable as soon as the stack frame for make_warrior is unwound. Furthermore, the space allocated to $fighter doesn't get freed as long as there is a reference to it, and $soldier is such a reference. As long as something needs the space, it remains allocated, and as soon as nothing needs it, it gets freed. This is what you're used to spending all that time agonizing about in C.

Functions don't need () after them if you have no arguments to supply them, but if you do this with functions of your own, then their definition (or a prototype declaration) should precede their use.

Although in C the expressions a[i] and i[a] are equivalent, the corresponding expressions in Perl are not. If you find this surprising, you may need more help than we can provide.

While Perl inherits many operators (and their precedence) from C and probably strives hardest to be accessible to the C programmer, it also strives to be as orthogonal as possible. For example, while Perl provides the same && and || operators as C, they return their inputs instead of a Boolean value. In other words, $a || $b is $a if $a is true; otherwise it is $b. (The operators short-circuit the same way). In another example, Perl figures anything that could be an lvalue, should be, so a term containing the trinary (?:) operator is an lvalue if its left and right parts are lvalues. The substr function is an lvalue if the result of its first argument is modifiable. And as of version 5.6.0, you can even (in an experimental feature) create a function of your own that is an lvalue.

Although no switch statement exists in Perl, this hasn't stopped people from inventing several dozen ways of simulating one, the latest being Switch.pm, a module presented by Damian Conway at the fourth annual Perl Conference (http://conference.perl.com/). The reason there isn't a switch is that when you start implementing one, your average switch statement seems very limited when you consider the breadth of Perl's operators. Why should each case be just a simple test for equality? Why not be able to compare against a regular expression as well? (Even the Bourne shell manages that.) Why shut out the vast set of logical comparisons? Until Switch.pm, it appeared that nothing could be implemented that wouldn't look like a poor cousin to the rest of the language. (It now seems that some version of Switch.pm will be incorporated into the core Perl 6 language.)

Hierarchical data structures are thoroughly typeless (atypical?) in Perl; no more fiddling with union statements to traverse heterogeneous lists. Sometimes, people are afraid this means that they must pedantically check the type of every element of a complex object themselves to make sure they don't dereference something incorrectly; that is, until they realize that they were probably the ones who constructed the object in the first place, and they can usually trust themselves.

Don't look for a counterpart to struct expecting that you'll use it nearly as much. If you want to achieve exactly the same effect (named members of a compound variable) you can do so with a reference to a hash (or an object); but in practice, most of the uses you'd have for those things aren't necessary. There's no need to write special code for linked lists (although there's a book that shows you how if you have some exotic need^[3]); Perl's arrays grow on demand quite well enough. Most of the reasons to construct trees are taken care of by Perl's efficient algorithm for looking up elements in hashes. (Again, if you have a need that somehow manages to overwhelm this mechanism, the same book provides alternatives.)

^[3] Mastering Algorithms with Perl, by Jon Orwant, Jarkko Hietaniemi and John Macdonald (O'Reilly, 1999).

Some of the system calls you're accustomed to look like they were taken behind the woodshed by the tool set and given a workover to extend their usefulness. Instead of taking just one file as argument, chmod, chown, and unlink all take a list of filenames as arguments instead of just one. Oddly enough, mkdir and rmdir do not take lists of directory names even though their command line counterparts do.

'lint' is spelled 'use strict' and '-w' in Perl.