[perldocjp-cvs 1523] CVS update: docs/perl/5.10.0

Back to archive index

argra****@users***** argra****@users*****
2012年 8月 29日 (水) 21:44:14 JST


Index: docs/perl/5.10.0/perlguts.pod
diff -u docs/perl/5.10.0/perlguts.pod:1.11 docs/perl/5.10.0/perlguts.pod:1.12
--- docs/perl/5.10.0/perlguts.pod:1.11	Sun Aug 19 18:32:11 2012
+++ docs/perl/5.10.0/perlguts.pod	Wed Aug 29 21:44:13 2012
@@ -586,7 +586,7 @@
 
 このコードは、実値を返さなければならないときには、(値として 42 を
 持つ) 新しい SV を返そうとし、さもなくば undef を返そうとします。
-ですが、どこかの行でナルポインタを返して、セグメントバイオレーションが
+ですが、どこかの行でヌルポインタを返して、セグメントバイオレーションが
 起こるか、何かおかしな結果になってしまいます。
 最初の行の 0 を C<&PL_sv_undef> に変えれば、すべてがうまくいきます。
 
@@ -619,16 +619,15 @@
 
 =end original
 
-Perl provides the function C<sv_chop> to efficiently remove characters
-from the beginning of a string; you give it an SV and a pointer to
-somewhere inside the PV, and it discards everything before the
-pointer. The efficiency comes by means of a little hack: instead of
-actually removing the characters, C<sv_chop> sets the flag C<OOK>
-(offset OK) to signal to other functions that the offset hack is in
-effect, and it puts the number of bytes chopped off into the IV field
-of the SV. It then moves the PV pointer (called C<SvPVX>) forward that
-many bytes, and adjusts C<SvCUR> and C<SvLEN>.
-(TBT)
+Perl は文字列の先頭から効率的に文字を削除するための関数 C<sv_chop> を
+提供されています; これに SV と、PV の内側のどこかへのポインタを渡すと、
+そのポインタより手前の全てを削除します。
+効率性はちょっとしたハックによるものです: 実際に文字を削除する代わりに、
+C<sv_chop> は、他の関数にオフセットハックが有効であることを示す C<OOK>
+(offset OK) フラグを設定して、SV の IV フィールドに、切り落とすバイト数を
+設定します。
+それから(C<SvPVX> と呼ばれる)PV ポインタを移動させて、C<SvCUR> と
+C<SvLEN> を調整します。
 
 =begin original
 
@@ -638,10 +637,9 @@
 
 =end original
 
-Hence, at this point, the start of the buffer that we allocated lives
-at C<SvPVX(sv) - SvIV(sv)> in memory and the PV pointer is pointing
-into the middle of this allocated storage.
-(TBT)
+従って、この時点で、割り当てられたバッファの先頭はメモリ中の
+C<SvPVX(sv) - SvIV(sv)> であり、PV ポインタは割り当てられた保管領域の中間を
+指しています。
 
 =begin original
 
@@ -670,12 +668,10 @@
 
 =end original
 
-Here the number of bytes chopped off (1) is put into IV, and
-C<Devel::Peek::Dump> helpfully reminds us that this is an offset. The
-portion of the string between the "real" and the "fake" beginnings is
-shown in parentheses, and the values of C<SvCUR> and C<SvLEN> reflect
-the fake beginning, not the real one.
-(TBT)
+ここで切り落とされたバイト数 (1) は IV に設定され、C<Devel::Peek::Dump> は
+これがオフセットであることを示す助けをしてくれます。
+「実際」と「偽物」の開始の間の文字列の部分はかっこで示され、
+C<SvCUR> と C<SvLEN> の値は実際のものではなく偽物の先頭を反映します。
 
 =begin original
 
@@ -690,15 +686,14 @@
 
 =end original
 
-Something similar to the offset hack is performed on AVs to enable
-efficient shifting and splicing off the beginning of the array; while
-C<AvARRAY> points to the first element in the array that is visible from
-Perl, C<AvALLOC> points to the real start of the C array. These are
-usually the same, but a C<shift> operation can be carried out by
-increasing C<AvARRAY> by one and decreasing C<AvFILL> and C<AvLEN>.
-Again, the location of the real start of the C array only comes into
-play when freeing the array. See C<av_shift> in F<av.c>.
-(TBT)
+オフセットハックと似たようなものは、配列の先頭の効率的なシフトと切り落としを
+有効にするために AV に対しても行われます; 
+C<AvARRAY> は Perl から見える配列の最初の要素を指していますが、C<AvALLOC> は
+C の配列の実際の先頭を指しています。
+これらは普通は同じですが、C<shift> 演算子は C<AvARRAY> を一つ増やして、
+C<AvFILL> と C<AvLEN> を一つ減らします。
+再び、C の配列の実際の先頭の一は、配列を解放するときにだけ使われます。
+F<av.c> の C<av_shift> を参照してください。
 
 =head2 What's Really Stored in an SV?
 
@@ -745,6 +740,7 @@
 というマクロを代わりに使うことができます。
 これらのマクロは、実際に SV に入っているものが整数か、倍精度か、
 文字列ポインタかを教えてくれます。
+"p" はプライベートの意味です。
 
 =begin original
 
@@ -758,14 +754,14 @@
 
 =end original
 
-The are various ways in which the private and public flags may differ.
-For example, a tied SV may have a valid underlying value in the IV slot
-(so SvIOKp is true), but the data should be accessed via the FETCH
-routine rather than directly, so SvIOK is false. Another is when
-numeric conversion has occurred and precision has been lost: only the
-private flag is set on 'lossy' values. So when an NV is converted to an
-IV with loss, SvIOKp, SvNOKp and SvNOK will be set, while SvIOK wont be.
-(TBT)
+プライベートと公的なフラグが異なるのは様々な方法があります。
+例えば、tie された SV は IV スロットに妥当な値を保持している
+(従って SvIOKp は真) かもしれませんが、データは直接ではなく FETCH ルーチンを
+通してアクセスされるべきなため、SvIOK は偽です。
+他の例としては数値変換が起こり、精度が落ちた場合です:プライベートな
+フラグのみが「精度が落ちた」値に設定されます。
+それで、NV が精度が落ちる形で IV に変換されると、SvIOKp, SvNOKp, SvNOK は
+設定されますが、SvIOK は設定されません。
 
 =begin original
 
@@ -1335,11 +1331,10 @@
 
 =end original
 
-In perl 5.8.0, C<&PL_sv_undef> was also used to mark placeholders
-in restricted hashes. This caused such hash entries not to appear
-when iterating over the hash or when checking for the keys
-with the C<hv_exists> function.
-(TBT)
+perl 5.8.0 では、C<&PL_sv_undef> は制限ハッシュのプレースホルダを
+マークするためにも使われていました。
+これは、ハッシュを反復するときや C<hv_exists> 関数でキーを
+チェックするときには、そのようなハッシュエントリは現れないということです。
 
 =begin original
 
@@ -1349,10 +1344,9 @@
 
 =end original
 
-You can run into similar problems when you store C<&PL_sv_true> or
-C<&PL_sv_false> into AVs or HVs. Trying to modify such elements
-will give you the following error:
-(TBT)
+C<&PL_sv_true> や C<&PL_sv_false> を AV や HV に保管するときにも同じような
+問題が起こります。
+このような要素を修正しようとすると、以下のようなエラーが出ます:
 
     Modification of a read-only value attempted
 
@@ -1364,10 +1358,9 @@
 
 =end original
 
-To make a long story short, you can use the special variables
-C<&PL_sv_undef>, C<&PL_sv_true> and C<&PL_sv_false> with AVs and
-HVs, but you have to make sure you know what you're doing.
-(TBT)
+長い物語を短くすると、特殊変数 C<&PL_sv_undef>, C<&PL_sv_true>,
+C<&PL_sv_false> を AV や HV に使えますが、何をしているかを知っている必要が
+あります。
 
 =begin original
 
@@ -1377,10 +1370,8 @@
 
 =end original
 
-Generally, if you want to store an undefined value in an AV
-or HV, you should not use C<&PL_sv_undef>, but rather create a
-new undefined value using the C<newSV> function, for example:
-(TBT)
+一般的に、AV や HV に未定義値を保管したいなら、C<&PL_sv_undef> を使わず、
+C<newSV> 関数を使って新しい未定義値を使ってください; 例えば:
 
     av_store( av, 42, newSV(0) );
     hv_store( hv, "foo", 3, newSV(0), 0 );
@@ -1396,8 +1387,7 @@
 
 =end original
 
-リファレンスは、(リファレンスを含む) 他のスカラ型を指す特別な
-スカラ型です。
+リファレンスは、(リファレンスを含む) 他のスカラ型を指す特別なスカラ型です。
 
 =begin original
 
@@ -1453,8 +1443,8 @@
 
 =end original
 
-SV がリファレンスであるかどうかを確認するために、
-以下のマクロを使うことができます。
+SV がリファレンスであるかどうかを確認するために、以下のマクロを
+使うことができます。
 
     SvROK(SV*)
 
@@ -1465,8 +1455,8 @@
 
 =end original
 
-リファレンスが参照している型を見つけるために、以下のマクロを
-使いその戻り値をチェックします。
+リファレンスが参照している型を見つけるために、以下のマクロを使いその戻り値を
+チェックします。
 
     SvTYPE(SvRV(SV*))
 
@@ -1571,7 +1561,7 @@
 
 まだ存在していなければ、rv をリファレンスにアップグレードします。
 rv が指し示すための新たな SV を生成します。
-C<classname> がナルでなければ、SV は指定されたクラスに bless され、
+C<classname> がヌルでなければ、SV は指定されたクラスに bless され、
 SV が返されます。
 
 	SV* newSVrv(SV* rv, const char* classname);
@@ -1584,7 +1574,7 @@
 =end original
 
 整数、符号なし整数、倍精度実数を C<rv> が参照している SV へコピーします。
-SV は C<classname> がナルでなければblessされます。
+SV は C<classname> がヌルでなければ bless されます。
 
 	SV* sv_setref_iv(SV* rv, const char* classname, IV iv);
 	SV* sv_setref_uv(SV* rv, const char* classname, UV uv);
@@ -1598,8 +1588,8 @@
 =end original
 
 ポインタ値(B<アドレスであって、文字列ではありません!>)を rv が
-参照しているSVへコピーします。
-SV は C<classname> がナルでなければ bless されます。
+参照している SV へコピーします。
+SV は C<classname> がヌルでなければ bless されます。
 
 	SV* sv_setref_pv(SV* rv, const char* classname, PV iv);
 
@@ -1612,7 +1602,7 @@
 
 文字列を C<rv> が参照している SV へコピーします。
 length に 0 を設定すると、Perl が文字列の長さを計算します。
-SV は C<classname> がナルでなければ bless されます。
+SV は C<classname> がヌルでなければ bless されます。
 
 	SV* sv_setref_pvn(SV* rv, const char* classname, PV iv, STRLEN length);
 
@@ -2376,7 +2366,7 @@
 これが C<sv> 引数と同じでなかった場合、C<obj> の参照カウントは
 インクリメントされます。
 同じであった場合、もしくは引数 C<how> が
-C<PERL_MAGIC_arylen> かナルポインタであった場合には、C<obj> は
+C<PERL_MAGIC_arylen> かヌルポインタであった場合には、C<obj> は
 参照カウントのインクリメントをさせることなく格納されます。
 
 =begin original
@@ -3898,9 +3888,9 @@
 
 =end original
 
-Because the target is reused, you must be careful when pushing multiple
-values on the stack. The following code will not do what you think:
-(TBT)
+ターゲットは再利用されるので、スタックに複数の値をプッシュするときには
+注意しなければなりません。
+以下のコードはあなたが考えているようには動作しません:
 
     XPUSHi(10);
     XPUSHi(20);
@@ -3915,12 +3905,11 @@
 
 =end original
 
-This translates as "set C<TARG> to 10, push a pointer to C<TARG> onto
-the stack; set C<TARG> to 20, push a pointer to C<TARG> onto the stack".
-At the end of the operation, the stack does not contain the values 10
-and 20, but actually contains two pointers to C<TARG>, which we have set
-to 20.
-(TBT)
+これは、「C<TARG> に 10 を設定して、C<TARG> へのポインタをスタックに
+プッシュする; C<TARG> に 20 を設定して、C<TARG> へのポインタをスタックに
+プッシュする」と解釈されます。
+操作の終了時、スタックには値 10 と 20 はなく、値 を 20 に設定された
+C<TARG> へのポインタが二つあります。
 
 =begin original
 
@@ -3936,16 +3925,15 @@
 
 =end original
 
-If you need to push multiple different values then you should either use
-the C<(X)PUSHs> macros, or else use the new C<m(X)PUSH[iunp]> macros,
-none of which make use of C<TARG>.  The C<(X)PUSHs> macros simply push an
-SV* on the stack, which, as noted under L</XSUBs and the Argument Stack>,
-will often need to be "mortal".  The new C<m(X)PUSH[iunp]> macros make
-this a little easier to achieve by creating a new mortal for you (via
-C<(X)PUSHmortal>), pushing that onto the stack (extending it if necessary
-in the case of the C<mXPUSH[iunp]> macros), and then setting its value.
-Thus, instead of writing this to "fix" the example above:
-(TBT)
+複数の異なった値をプッシュしたい場合、C<(X)PUSHs> マクロを使うか、新しい
+C<m(X)PUSH[iunp]> マクロを使う必要があります; どちらもC<TARG> は使いません。
+C<(X)PUSHs> マクロは単に SV* をスタックにプッシュし、この値は、
+L</XSUBs and the Argument Stack> で注意されているように、
+しばしば「揮発性」である必要があります。
+新しい C<m(X)PUSH[iunp]> マクロは、新しい揮発性値を
+(C<(X)PUSHmortal> を使って)作成し、それをスタックにプッシュし
+(C<mXPUSH[iunp]> マクロの場合もし必要なら拡張して)、それから値を設定します。
+従って、前述の例を「修正」するのに以下のように書く代わりに:
 
     XPUSHs(sv_2mortal(newSViv(10)))
     XPUSHs(sv_2mortal(newSViv(20)))
@@ -3956,8 +3944,7 @@
 
 =end original
 
-you can simply write:
-(TBT)
+単純にこう書けます:
 
     mXPUSHi(10)
     mXPUSHi(20)
@@ -3971,11 +3958,9 @@
 
 =end original
 
-On a related note, if you do use C<(X)PUSH[iunp]>, then you're going to
-need a C<dTARG> in your variable declarations so that the C<*PUSH*>
-macros can make use of the local variable C<TARG>.  See also C<dTARGET>
-and C<dXSTARG>.
-(TBT)
+関連する注意として、C<(X)PUSH[iunp]> を使うなら、C<*PUSH*> マクロが
+ローカル変数 C<TARG> を使うように、変数宣言に C<dTARG> が必要でしょう。
+C<dTARGET> と C<dXSTARG> も参照してください。
 
 =head2 Scratchpads
 
@@ -4249,15 +4234,13 @@
 
 =end original
 
-Each of these nodes represents an op, a fundamental operation inside the
-Perl core. The code which implements each operation can be found in the
-F<pp*.c> files; the function which implements the op with type C<gvsv>
-is C<pp_gvsv>, and so on. As the tree above shows, different ops have
-different numbers of children: C<add> is a binary operator, as one would
-expect, and so has two children. To accommodate the various different
-numbers of children, there are various types of op data structure, and
-they link together in different ways.
-(TBT)
+ノードのそれぞれは op を示し、これは Perl コア内部の基本的な操作です。
+それぞれの操作を実装しているコードは F<pp*.c> ファイルにあります;
+C<gvsv> 型の op を実装している関数は C<pp_gvsv>、といった形です。
+上述の木において、異なった op は異なった数の子を持ちます: C<add> は
+二項演算子で、推測される通り、二つの子を持ちます。
+様々に異なる数の子に対応するために、op データ構造には様々な種類があり、
+異なった方法で互いにリンクしています。
 
 =begin original
 
@@ -4272,15 +4255,16 @@
 
 =end original
 
-The simplest type of op structure is C<OP>: this has no children. Unary
-operators, C<UNOP>s, have one child, and this is pointed to by the
-C<op_first> field. Binary operators (C<BINOP>s) have not only an
-C<op_first> field but also an C<op_last> field. The most complex type of
-op is a C<LISTOP>, which has any number of children. In this case, the
-first child is pointed to by C<op_first> and the last child by
-C<op_last>. The children in between can be found by iteratively
-following the C<op_sibling> pointer from the first child to the last.
-(TBT)
+op 構造体の最も単純な型は C<OP> です: これは子はありません。
+単項演算子である C<UNOP> は一つの子を持ち、これは C<op_first>
+フィールドによって示されています。
+二項演算子 (C<BINOP>) は C<op_first> フィールドだけでなく
+C<op_last> フィールドも持ちます。
+最も複雑な op の型は C<LISTOP> で、任意の数の子を持ちます。
+この場合、最初の子は C<op_first> で示され、最後の子は C<op_last> で
+示されます。
+その間の子は、最初の子から最後の子まで C<op_sibling> ポインタを反復的に
+辿ることで見つけられます。
 
 =begin original
 
@@ -4293,13 +4277,12 @@
 
 =end original
 
-There are also two other op types: a C<PMOP> holds a regular expression,
-and has no children, and a C<LOOP> may or may not have children. If the
-C<op_children> field is non-zero, it behaves like a C<LISTOP>. To
-complicate matters, if a C<UNOP> is actually a C<null> op after
-optimization (see L</Compile pass 2: context propagation>) it will still
-have children in accordance with its former type.
-(TBT)
+あと二つの op 型があります: C<PMOP> は正規表現を保持し、子はありません;
+また C<LOOP> は子があるかもしれませんしないかもしれません。
+C<op_children> フィールドが非ゼロなら、C<LISTOP> のように振る舞います。
+問題を複雑にするために、もし C<UNOP> が最適化の後実際には
+C<null> op になった場合 (L</Compile pass 2: context propagation> を
+参照してください)、これは以前の形に一致する形で子を持ちます。
 
 =begin original
 
@@ -4308,9 +4291,8 @@
 
 =end original
 
-Another way to examine the tree is to use a compiler back-end module, such
-as L<B::Concise>.
-(TBT)
+木を調べるその他の方法は、L<B::Concise> のようなコンパイラバックエンド
+モジュールを使うことです。
 
 =head2 Compile pass 1: check routines
 
@@ -4399,11 +4381,10 @@
 
 =end original
 
-チェックルーチンが呼び出された直後に、返されたノードはコンパイル時
-実行のためのチェックが行なわれます。
-もしそうであれば(値が定数であると判定された)、そのノードは即座に
-実行されて、「戻り値」に対応する部分木は B<定数> ノードで置換され、
-部分木が削除されます。
+チェックルーチンが呼び出された直後に、返されたノードはコンパイル時実行の
+ためのチェックが行なわれます。
+もしそうであれば(値が定数であると判定された)、そのノードは即座に実行されて、
+「戻り値」に対応する部分木は B<定数> ノードで置換され、部分木が削除されます。
 
 =begin original
 
@@ -4429,8 +4410,7 @@
 
 =end original
 
-解析木の一部分のコンテキストがわかっているとき、それは木の末端へ
-伝播します。
+解析木の一部分のコンテキストがわかっているとき、それは木の末端へ伝播します。
 このとき、コンテキストは(実行時コンテキストの二種類ではなく)
 無効、真偽値、スカラ、リスト、左辺値の五種類の値を持つことができます。
 パス 1 とは対照的に、このパスではトップから末端へと処理が進みます。
@@ -4447,11 +4427,11 @@
 =end original
 
 コンテキストに依存した最適化はこのときに行なわれます。
-この動作では解析木が(“スレッド”ポインタを通じて)後方参照を
-含んでいるので、ノードをこの時に free() することはできません。
+この動作では解析木が(“スレッド”ポインタを通じて)後方参照を含んでいるので、
+ノードをこの時に free() することはできません。
 このステージでノードを最適化するのを許すために、対象となるノードは
-free() されるかわりに null() されます(つまり、そのノードの型が
-OP_NULL に変えられるということ)。
+free() されるかわりに null() されます(つまり、そのノードの型が OP_NULL に
+変えられるということ)。
 
 =head2 Compile pass 3: peephole optimization
 
@@ -4470,8 +4450,8 @@
 
 サブルーチン(もしくは C<eval> かファイル)に対する解析木が生成された後で、
 そのコードに対する追加パスが実行されます。
-このパスはトップダウンでもボトムアップでもなく、(条件に対する
-複雑さを伴った)実行順序です。
+このパスはトップダウンでもボトムアップでもなく、(条件に対する複雑さを伴った)
+実行順序です。
 これらの最適化はサブルーチン peep() で行なわれます。
 このステージで行なわれる最適化はパス 2 でのものと同じ制限に従います。
 
@@ -4489,12 +4469,12 @@
 
 =end original
 
-The compile tree is executed in a runops function.  There are two runops
-functions, in F<run.c> and in F<dump.c>.  C<Perl_runops_debug> is used
-with DEBUGGING and C<Perl_runops_standard> is used otherwise.  For fine
-control over the execution of the compile tree it is possible to provide
-your own runops function.
-(TBT)
+コンパイル木は runops 関数で実行されます。
+F<run.c> と F<dump.c> に二つの関数があります。
+C<Perl_runops_debug> は DEBUGGING で使われ、C<Perl_runops_standard> は
+その他で使われます。
+コンパイル木の実行を細かく制御するために、独自の runops 関数を
+設定できます。
 
 =begin original
 
@@ -4504,10 +4484,9 @@
 
 =end original
 
-It's probably best to copy one of the existing runops functions and
-change it to suit your needs.  Then, in the BOOT section of your XS
-file, add the line:
-(TBT)
+既にある runops 関数の一つをコピーして、必要性に合わせて変更するのが
+おそらく最良です。
+それから、XS ファイルの BOOT セクションに、以下の行を追加します:
 
   PL_runops = my_runops;
 
@@ -4518,9 +4497,8 @@
 
 =end original
 
-This function should be as efficient as possible to keep your programs
-running as fast as possible.
-(TBT)
+この関数はプログラムを出来るだけ早く実行し続けられるように、出来るだけ
+効率的にするべきです。
 
 =head1 Examining internal data structures with the C<dump> functions
 
@@ -4533,9 +4511,8 @@
 
 =end original
 
-To aid debugging, the source file F<dump.c> contains a number of
-functions which produce formatted output of internal data structures.
-(TBT)
+デバッグを助けるために、ソースファイル F<dump.c> に内部データ構造の
+フォーマットした出力を生成する多くの関数があります。
 
 =begin original
 
@@ -4546,11 +4523,11 @@
 
 =end original
 
-The most commonly used of these functions is C<Perl_sv_dump>; it's used
-for dumping SVs, AVs, HVs, and CVs. The C<Devel::Peek> module calls
-C<sv_dump> to produce debugging output from Perl-space, so users of that
-module should already be familiar with its format.
-(TBT)
+これらの関数で最もよく使われるものは C<Perl_sv_dump> です; これは
+SV, AV, HV, CV をダンプするために使います。
+C<Devel::Peek> モジュールは、Perl 空間からのデバッグ出力を作成するために
+C<sv_dump> を呼び出すので、このモジュールのユーザーは既にこのフォーマットに
+親しみがあるはずです。
 
 =begin original
 
@@ -4561,11 +4538,9 @@
 
 =end original
 
-C<Perl_op_dump> can be used to dump an C<OP> structure or any of its
-derivatives, and produces output similar to C<perl -Dx>; in fact,
-C<Perl_dump_eval> will dump the main root of the code being evaluated,
-exactly like C<-Dx>.
-(TBT)
+C<Perl_op_dump> は、C<OP> 構造体やその派生をダンプするために使い、
+C<perl -Dx> と同様の出力を作成します; 実際のところ、C<Perl_dump_eval> は
+C<-Dx> と正確に同じように、評価されたコードの main ルートをダンプします。
 
 =begin original
 
@@ -4576,11 +4551,10 @@
 
 =end original
 
-Other useful functions are C<Perl_dump_sub>, which turns a C<GV> into an
-op tree, C<Perl_dump_packsubs> which calls C<Perl_dump_sub> on all the
-subroutines in a package like so: (Thankfully, these are all xsubs, so
-there is no op tree)
-(TBT)
+その他の有用な関数は、C<GV> を op 木に変換する C<Perl_dump_sub> と、
+パッケージの全てのサブルーチンで C<Perl_dump_sub> を呼び出す
+C<Perl_dump_packsubs>: (ありがたいことに、これらは全て xsub なので、
+op 木はありません)
 
     (gdb) print Perl_dump_packsubs(PL_defstash)
 
@@ -4601,9 +4575,8 @@
 
 =end original
 
-and C<Perl_dump_all>, which dumps all the subroutines in the stash and
-the op tree of the main root.
-(TBT)
+および、stash の全てのサブルーチンと main ルートの op 木をダンプする
+C<Perl_dump_all> です。
 
 =head1 How multiple interpreters and concurrency are supported
 
@@ -5308,12 +5281,11 @@
 
 =end original
 
-All of Perl's internal functions which will be exposed to the outside
-world are prefixed by C<Perl_> so that they will not conflict with XS
-functions or functions used in a program in which Perl is embedded.
-Similarly, all global variables begin with C<PL_>. (By convention,
-static functions start with C<S_>.)
-(TBT)
+外部の世界に曝されている Perl の内部関数の全ては C<Perl_> の接頭辞が
+ついているので、XS 関数や Perl が組み込まれている関数で使われている関数と
+衝突しません。
+同様に、全てのグローバル変数は C<PL_> で始まります。
+(慣例的に、静的関数は C<S_> で始まります。)
 
 =begin original
 
@@ -5329,16 +5301,14 @@
 
 =end original
 
-Inside the Perl core, you can get at the functions either with or
-without the C<Perl_> prefix, thanks to a bunch of defines that live in
-F<embed.h>. This header file is generated automatically from
-F<embed.pl> and F<embed.fnc>. F<embed.pl> also creates the prototyping
-header files for the internal functions, generates the documentation
-and a lot of other bits and pieces. It's important that when you add
-a new function to the core or change an existing one, you change the
-data in the table in F<embed.fnc> as well. Here's a sample entry from
-that table:
-(TBT)
+Perl コアの内側では、F<embed.h> にあるたくさんの define のおかげで、
+C<Perl_> 接頭辞ありとなしのどちらかの関数を使えます。
+このヘッダファイルは F<embed.pl> と F<embed.fnc> から自動的に生成されます。
+F<embed.pl> は内部関数のためのヘッダファイルのプロトタイプも作成し、
+その他の多くの欠片の文書も生成します。
+新しい関数をコアに追加したり既にあるものを変更したりした場合、
+F<embed.fnc> にある表のデータも変更することが重要です。
+以下はその表のエントリの例です:
 
     Apd |SV**   |av_fetch   |AV* ar|I32 key|I32 lval
 
@@ -6203,10 +6173,9 @@
 
 =end original
 
-If you're mixing UTF-8 and non-UTF-8 strings, it is necessary to upgrade
-one of the strings to UTF-8. If you've got an SV, the easiest way to do
-this is:
-(TBT)
+UTF-8 と non-UTF-8 の文字列を混ぜるなら、文字列の片方を UTF-8 に
+昇格させる必要があります。
+SV を使っているなら、これをするのに最も簡単な方法は:
 
     sv_utf8_upgrade(sv);
 
@@ -6216,8 +6185,7 @@
 
 =end original
 
-However, you must not do this, for example:
-(TBT)
+しかし、例えば以下のようにしてはいけません:
 
     if (!SvUTF8(left))
         sv_utf8_upgrade(left);
@@ -6230,10 +6198,9 @@
 
 =end original
 
-If you do this in a binary operator, you will actually change one of the
-strings that came into the operator, and, while it shouldn't be noticeable
-by the end user, it can cause problems in deficient code.
-(TBT)
+これを二項演算子で行うなら、演算子から来る文字列の一つを実際に変更し、
+エンドユーザーは気がつくべきではない一方、不完全なコードによる
+問題を引き起こすかもしれません。
 
 =begin original
 
@@ -6246,13 +6213,13 @@
 
 =end original
 
-Instead, C<bytes_to_utf8> will give you a UTF-8-encoded B<copy> of its
-string argument. This is useful for having the data available for
-comparisons and so on, without harming the original SV. There's also
-C<utf8_to_bytes> to go the other way, but naturally, this will fail if
-the string contains any characters above 255 that can't be represented
-in a single byte.
-(TBT)
+代わりに、C<bytes_to_utf8> は、文字列引数を UTF-8 でエンコードした
+B<コピー> を作ります。
+これは、元の SV に影響を与えることなく、比較などに使えるデータを作るのに
+有用です。
+また、逆方向を自然に行う C<utf8_to_bytes> もあります; これは文字列に
+単一バイトで表現できない、番号 255 を超える文字が含まれていると
+失敗します。
 
 =head2 Is there anything else I need to know?
 
@@ -6280,11 +6247,11 @@
 
 =end original
 
-There's no way to tell if a string is UTF-8 or not. You can tell if an SV
-is UTF-8 by looking at is C<SvUTF8> flag. Don't forget to set the flag if
-something should be UTF-8. Treat the flag as part of the PV, even though
-it's not - if you pass on the PV to somewhere, pass on the flag too.
-(TBT)
+文字列が UTF-8 かどうかを知らせる方法はありません。
+SV が UTF-8 であるなら C<SvUTF8> フラグを見ることで分かります。
+何かが UTF-8 であるべきならフラグを設定することを忘れないでください。
+たとえそうでなくても、このフラグを PV の一部として扱ってください - PV を
+どこかに渡すときは、このフラグも渡してください。
 
 =item *
 
@@ -6295,9 +6262,8 @@
 
 =end original
 
-If a string is UTF-8, B<always> use C<utf8_to_uv> to get at the value,
-unless C<UTF8_IS_INVARIANT(*s)> in which case you can use C<*s>.
-(TBT)
+文字列が UTF-8 なら、値を得るときは B<常に> C<utf8_to_uv> を使ってください;
+但し、C<UTF8_IS_INVARIANT(*s)> の場合は C<*s> を使えます。
 
 =item *
 
@@ -6309,10 +6275,9 @@
 
 =end original
 
-When writing a character C<uv> to a UTF-8 string, B<always> use
-C<uv_to_utf8>, unless C<UTF8_IS_INVARIANT(uv))> in which case
-you can use C<*s = uv>.
-(TBT)
+文字 C<uv> を UTF-8 文字列を書き込むときは B<常に> C<uv_to_utf8> を
+使ってください; 但し、C<UTF8_IS_INVARIANT(uv))> の場合は C<*s = uv> を
+使えます。
 
 =item *
 
@@ -6325,11 +6290,12 @@
 
 =end original
 
-Mixing UTF-8 and non-UTF-8 strings is tricky. Use C<bytes_to_utf8> to get
-a new string which is UTF-8 encoded. There are tricks you can use to
-delay deciding whether you need to use a UTF-8 string until you get to a
-high character - C<HALF_UPGRADE> is one of those.
-(TBT)
+UTF-8 と 非 UTF-8 の文字列を混ぜるのはトリッキーです。
+UTF-8 エンコードされた新しい文字列を得るには C<bytes_to_utf8> を
+使ってください。
+UTF-8 文字列を使う必要があるかを決定するのを、最上位ビットが立った
+文字が来るまで遅延するのに使えるトリックがあります - C<HALF_UPGRADE> は
+その一つです。
 
 =back
 
@@ -6348,13 +6314,11 @@
 
 =end original
 
-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
-functions of multiple ops which are usually executed together, such as
-C<gvsv, gvsv, add>.)
-(TBT)
+カスタム演算子対応は独自の op を定義できる新しい実験的機能です。
+これは主に Perl コアに他の言語のためのインタプリタを
+構築できるようにするためのものですが、「マクロ op」
+(C<gvsv, gvsv, add> のように、普段一緒に実行される複数の op の関数を
+実行する op) を作成することで最適化できるようにもします。
 
 =begin original
 
@@ -6366,12 +6330,11 @@
 
 =end original
 
-This feature is implemented as a new op type, C<OP_CUSTOM>. The Perl
-core does not "know" anything special about this op type, and so it will
-not be involved in any optimizations. This also means that you can
-define your custom ops to be any op structure - unary, binary, list and
-so on - you like.
-(TBT)
+この機能は 新しい op 型である C<OP_CUSTOM> として実装されています。
+Perl コアはこの op 型について何も特別なことは「知りません」し、
+どのような最適化も行いません。
+これはまた、どのような op 構造 - 単項、二項、リストなど - でも
+好きなものになれるカスタム op を定義できるということです。 
 
 =begin original
 
@@ -6385,14 +6348,15 @@
 
 =end original
 
-It's important to know what custom operators won't do for you. They
-won't let you add new syntax to Perl, directly. They won't even let you
-add new keywords, directly. In fact, they won't change the way Perl
-compiles a program at all. You have to do those changes yourself, after
-Perl has compiled the program. You do this either by manipulating the op
-tree using a C<CHECK> block and the C<B::Generate> module, or by adding
-a custom peephole optimizer with the C<optimize> module.
-(TBT)
+カスタム演算子がしないことを知ることは重要です。
+これは Perl に直接新しい文法を追加するものではありません。
+これは直接新しいキーワードを追加するものではありません。
+実際のところ、Perl がプログラムする方法を何も変えません。
+これらの変更は、Perl がプログラムをコンパイルした後、自分でする
+必要があります。
+これは、C<CHECK> ブロックと C<B::Generate> モジュールを使って op 木を
+操作するか、C<optimize> モジュールでカスタム覗き穴最適化器を追加することで
+行います。
 
 =begin original
 
@@ -6405,13 +6369,12 @@
 
 =end original
 
-When you do this, you replace ordinary Perl ops with custom ops by
-creating ops with the type C<OP_CUSTOM> and the C<pp_addr> of your own
-PP function. This should be defined in XS code, and should look like
-the PP ops in C<pp_*.c>. You are responsible for ensuring that your op
-takes the appropriate number of values from the stack, and you are
-responsible for adding stack marks if necessary.
-(TBT)
+これを行うとき、C<OP_CUSTOM> 型と独自の PP 関数の C<pp_addr> を持つ
+カスタム op を作成して、普通の Perl op を置き換えます。
+これは XS コードで定義されるべきで、C<pp_*.c> の PP op のように
+見えるべきです。
+作成した op がスタックから適切な数の値を取ることと、必要ならスタックに
+マークを追加することは作成者が責任を持ちます。
 
 =begin original
 
@@ -6425,14 +6388,14 @@
 
 =end original
 
-You should also "register" your op with the Perl interpreter so that it
-can produce sensible error and warning messages. Since it is possible to
-have multiple custom ops within the one "logical" op type C<OP_CUSTOM>,
-Perl uses the value of C<< o->op_ppaddr >> as a key into the
-C<PL_custom_op_descs> and C<PL_custom_op_names> hashes. This means you
-need to enter a name and description for your op at the appropriate
-place in the C<PL_custom_op_names> and C<PL_custom_op_descs> hashes.
-(TBT)
+また、Perl インタプリタに作成した op を「登録」して、適切なエラーと
+警告メッセージを生成できるようにします。
+一つの「論理」op 型 C<OP_CUSTOM> に複数のカスタム op を
+含めることができるので、Perl は C<PL_custom_op_descs> と
+C<PL_custom_op_names> ハッシュのキーとして C<< o->op_ppaddr >> の値を
+使います。
+これは、C<PL_custom_op_names> と C<PL_custom_op_descs> ハッシュの適切な
+位置に作成した op の名前と説明を登録する必要があるということです。
 
 =begin original
 
@@ -6441,9 +6404,8 @@
 
 =end original
 
-Forthcoming versions of C<B::Generate> (version 1.0 and above) should
-directly support the creation of custom ops by name.
-(TBT)
+リリース予定のバージョンの C<B::Generate> (バージョン 1.0 以上) では
+名前によるカスタム op の作成に直接対応しています。
 
 =head1 AUTHORS
 



perldocjp-cvs メーリングリストの案内
Back to archive index