There are additional macros whose values may be bitwise OR'ed with the
C<TRUE> argument to enable certain extra features. Those bits are:
- GV_ADDMULTI Marks the variable as multiply defined, thus preventing the
- "Name <varname> used only once: possible typo" warning.
- GV_ADDWARN Issues the warning "Had to create <varname> unexpectedly" if
- the variable did not exist before the function was called.
+=over
+
+=item GV_ADDMULTI
+
+Marks the variable as multiply defined, thus preventing the:
+
+ Name <varname> used only once: possible typo
+
+warning.
+
+=over
+
+=item GV_ADDWARN
+
+Issues the warning:
+
+ Had to create <varname> unexpectedly
+
+if the variable did not exist before the function was called.
+
+=back
If you do not specify a package name, the variable is created in the current
package.
SV to a mortal SV (and thus defers a call to C<SvREFCNT_dec>), and the
third creates a mortal copy of an existing SV.
Because C<sv_newmortal> gives the new SV no value,it must normally be given one
-via C<sv_setpv>, C<sv_setiv> etc. :
+via C<sv_setpv>, C<sv_setiv>, etc. :
SV *tmp = sv_newmortal();
sv_setiv(tmp, an_integer);
aware that the behavior may change in the future, umm, without warning.
The perl tie function associates a variable with an object that implements
-the various GET, SET etc methods. To perform the equivalent of the perl
+the various GET, SET, etc methods. To perform the equivalent of the perl
tie function from an XSUB, you must mimic this behaviour. The code below
carries out the necessary steps - firstly it creates a new hash, and then
creates a second hash which it blesses into the class which will implement
The biggest difference is that the first construction would
reinstate the initial value of $var, irrespective of how control exits
-the block: C<goto>, C<return>, C<die>/C<eval> etc. It is a little bit
+the block: C<goto>, C<return>, C<die>/C<eval>, etc. It is a little bit
more efficient as well.
There is a way to achieve a similar task from C via Perl API: create a
All four routines return the number of arguments that the subroutine returned
on the Perl stack.
-These routines used to be called C<perl_call_sv> etc., before Perl v5.6.0,
+These routines used to be called C<perl_call_sv>, etc., before Perl v5.6.0,
but those names are now deprecated; macros of the same name are provided for
compatibility.
(initially) one element, and this element is the scratchpad AV. Why do
we need an extra level of indirection?
-The answer is B<recursion>, and maybe (sometime soon) B<threads>. Both
+The answer is B<recursion>, and maybe B<threads>. Both
these can create several execution pointers going into the same
subroutine. For the subroutine-child not write over the temporaries
for the subroutine-parent (lifespan of which covers the call to the
or inside a thread-specific structure. These structures contain all
the context, the state of that interpreter.
-Three macros control the major Perl build flavors: MULTIPLICITY, and
+Two macros control the major Perl build flavors: MULTIPLICITY and
USE_5005THREADS. The MULTIPLICITY build has a C structure
that packages all the interpreter state, and there is a similar thread-specific
data structure under USE_5005THREADS. In both cases,
=head1 Custom Operators
-Custom operator support is a new experimental feature that allows you do
+Custom operator support is a new experimental feature that allows you to
define your own ops. This is primarily to allow the building of
interpreters for other languages in the Perl core, but it also allows
optimizations through the creation of "macro-ops" (ops which perform the
projects / p5sagit/p5-mst-13.2.git / commitdiff