argra****@users*****
argra****@users*****
2009年 2月 5日 (木) 00:45:50 JST
Index: docs/perl/5.8.8/perlpacktut.pod
diff -u docs/perl/5.8.8/perlpacktut.pod:1.12 docs/perl/5.8.8/perlpacktut.pod:1.13
--- docs/perl/5.8.8/perlpacktut.pod:1.12 Mon Feb 2 00:48:03 2009
+++ docs/perl/5.8.8/perlpacktut.pod Thu Feb 5 00:45:50 2009
@@ -997,7 +997,7 @@
交換する場合にもこれらの pack コードを使うべきです。
理由は単純で、この順序が I<ネットワーク順序> として選ばれていて、標準を
恐れる全てのプログラムがこの慣例に従っているはずだからです。
-(This is, of course, a stern
+(This is, of course, a stern
backing for one of the Lilliputian parties and may well influence the
political development there.)
それで、もし何バイトあるかの長さを先に送ることでメッセージを送ることを
@@ -1047,13 +1047,11 @@
=end original
-浮動小数点数を pack するには、you have the choice between the
-pack codes C<f> and C<d> which pack into (or unpack from) single-precision or
-double-precision representation as it is provided by your system.
+浮動小数点数を pack するには、システムで提供されている単精度と倍精度の実数に
+pack する pack コード C<f> と C<d> の選択肢があります。
(実数に対してはネットワーク表現のようなものはないので、もし他の
コンピュータに実数を送りたい場合は、ネットワークの向こう側で何が起きるかが
完全に分かっているのでない限りは、ASCII 表現で我慢した方がよいです。)
-(TBT)
=head1 Exotic Templates
@@ -1564,12 +1562,13 @@
構成されたネットワークメッセージを見ました。
You'll find
that packing a length followed by so many bytes of data is a
-frequently used recipe since appending a null byte won't work
-if a null byte may be part of the data.
+frequently used recipe
+NUL バイトを追加するというのは、データの一部として NUL バイトが
+含まれているときには動作しないので、引き続くデータの長さを pack するという
+方法はよく見られます。
以下は両方の技術を使った例です: 送り元と送り先のアドレスを示す 2 つの
NUL 終端文字列の後、(携帯電話への)ショートメッセージがその長さの後に
送られます:
-(TBT)
my $msg = pack( 'Z*Z*CA*', $src, $dst, length( $sm ), $sm );
@@ -1712,9 +1711,10 @@
=end original
-So far, we've seen literals used as templates. If the list of pack
-items doesn't have fixed length, an expression constructing the
-template is required (whenever, for some reason, C<()*> cannot be used).
+これまでは、テンプレートとして使われるリテラルを見てきました。
+pack するアイテムのリストが固定長でない場合(何らかの理由で C<()*> が
+使えないなら)、テンプレートを構成する式が必要です。
+以下は例です:
Here's an example: To store named string values in a way that can be
conveniently parsed by a C program, we create a sequence of names and
null terminated ASCII strings, with C<=> between the name and the value,
@@ -1737,7 +1737,8 @@
=end original
-Let's examine the cogs of this byte mill, one by one. There's the C<map>
+このバイト処理機の要素を一つ一つ調査してみましょう。
+There's the C<map>
call, creating the items we intend to stuff into the C<$env> buffer:
to each key (in C<$_>) it adds the C<=> separator and the hash entry value.
Each triplet is packed with the template code sequence C<A*A*Z*> that
@@ -1829,11 +1830,10 @@
=end original
前のセクションで、数値と文字列を pack する方法を見ました。
-If it were not for a couple of snags we could conclude this
-section right away with the terse remark that C structures don't
-contain anything else, and therefore you already know all there is to it.
-すみません、違います: どうか読み進めてください。
-(TBT)
+もしここに障害がないなら、「C 構造体には他に何もなく、従ってあなたは
+既に C 構造体を pack/unpack するための全てを知っています。」
+という簡潔な見解と共にこの章をすぐに締めくくることができます。
+すみません、そうではありません: どうか読み進めてください。
=head2 The Alignment Pit
@@ -1855,19 +1855,16 @@
=end original
-In the consideration of speed against memory requirements the balance
-has been tilted in favor of faster execution.
+速度とメモリ消費のバランスは、より速く実行できる方に傾いています。
これは C コンパイラが構造体のためにメモリを割り当てる方法に影響します:
-On architectures
-where a 16-bit or 32-bit operand can be moved faster between places in
-memory, or to or from a CPU register, if it is aligned at an even or
-multiple-of-four or even at a multiple-of eight address, a C compiler
-will give you this speed benefit by stuffing extra bytes into structures.
+偶数、4 の倍数、あるいは 8 の倍数のアドレスにアライメントされていれば、
+16 ビットや 32 ビットのオペランドや CPU レジスタへの出し入れが速くなる
+アーキテクチャでは、C コンパイラは構造体に追加のバイトを入れることで
+この速度メリットを受けるようにします。
もし C の海岸線を越えないのなら、これがなんらかの面倒を引き起こすことは
ありそうにありません (しかし、大きなデータ構造を設計したり、
アーキテクチャ間で移植性のあるコードがほしい場合(そうしたくないですか?)、
気にするべきです。)。
-(TBT)
=begin original
@@ -1943,7 +1940,7 @@
自然な質問: 「なぜ Perl は隙間を埋め合わせられないの?」には答えるのが
当然です。
-One good reason is that C compilers might provide (non-ANSI)
+一つのよい理由は、that C compilers might provide (non-ANSI)
extensions permitting all sorts of fancy control over the way structures
are aligned, even at the level of an individual structure field. And, if
this were not enough, there is an insidious thing called C<union> where
@@ -1975,13 +1972,13 @@
=end original
-C<l> の後の C<!> に注意してください: We want to make sure that we pack a long
-integer as it is compiled by our C compiler. And even now, it will only
-work for the platforms where the compiler aligns things as above.
-And somebody somewhere has a platform where it doesn't.
+C<l> の後の C<!> に注意してください: long 整数を C コンパイラで
+コンパイルされるのと同じ形になるのを確実にしたいです。
+そしてこの時点でも、これはコンパイラが上述のようにアライメントする
+プラットフォームでのみ動作します。
+そしてどこかの誰かはそうでないプラットフォームを使っています。
[おそらくは、Cray です; これは C<short>, C<int>, C<long> が全て
8 バイトです。:-)]
-(TBT)
=begin original
@@ -1991,10 +1988,9 @@
=end original
-Counting bytes and watching alignments in lengthy structures is bound to
-be a drag. Isn't there a way we can create the template with a simple
-program? Here's a C program that does the trick:
-(TBT)
+とても長い構造体のバイト数を数えてアライメントを監視するのは面倒なことです。
+単純なプログラムでテンプレートを作る方法はないでしょうか?
+以下は技を使った C プログラムです:
#include <stdio.h>
#include <stddef.h>
@@ -2038,13 +2034,12 @@
=end original
-Gee, yet another template code - as if we hadn't plenty. But
-C<@> saves our day by enabling us to specify the offset from the beginning
-of the pack buffer to the next item: This is just the value
-the C<offsetof> macro (defined in C<E<lt>stddef.hE<gt>>) returns when
-given a C<struct> type and one of its field names ("member-designator" in
-C standardese).
-(TBT)
+げー、新しいテンプレートコードです - まだ十分ではありませんでした。
+しかし C<@> は次のアイテムのための pack バッファの先頭からのオフセットを
+指定できるようにすることで手間を省きます:
+これは単に、C<struct> 型とそのフィールド名(C 標準での「メンバ指定子」)を
+与えたときに (C<E<lt>stddef.hE<gt>> で定義されている)C<offsetof> マクロが
+返す値です。
=begin original
@@ -2244,11 +2239,10 @@
明らかに、これはポインタから unsigned long への、およびその逆の型キャストが
可能であることを仮定しています; これはしばしば動作しますが、普遍的な
原則として扱うべきではありません。
-- Now that we have this pointer the next question
-is: How can we put it to good use?
+- ここでこのポインタを得ましたが、次の質問は: これをうまく使うには
+どうするのがよいでしょう?
ポインタを想定している C 関数を呼び出す必要があります。
read(2) システムコールが心に浮かびます:
-(TBT)
ssize_t read(int fd, void *buf, size_t count);
@@ -2330,7 +2324,7 @@
=end original
-Now that we have seen C<P> at work, we might as well give C<p> a whirl.
+ここで C<P> の動作は見たので、同様に C<p> を試してみます。
Why do we need a second template code for packing pointers at all? The
answer lies behind the simple fact that an C<unpack> with C<p> promises
a null-terminated string starting at the address taken from the buffer,
@@ -2348,10 +2342,8 @@
=end original
-Albeit this is apt to be confusing: As a consequence of the length being
-implied by the string's length, a number after pack code C<p> is a repeat
-count, not a length as after C<P>.
-(TBT)
+それでもこれは混乱しがちです: 長さが文字列の長さを暗示しているので、
+C<p> の後の数値は繰り返し数であって、C<P> の後のように長さではありません。
=begin original
@@ -2363,9 +2355,10 @@
=end original
Using C<pack(..., $x)> with C<P> or C<p> to get the address where C<$x> is
-actually stored must be used with circumspection. Perl's internal machinery
-considers the relation between a variable and that address as its very own
-private matter and doesn't really care that we have obtained a copy. Therefore:
+actually stored must be used with circumspection.
+Perl の内部機構は変数とそのアドレスの関係をとてもプライベートな問題と
+考え、私たちがコピーを得たことを実際には気にしません。
+従って:
(TBT)
=over 4
@@ -2411,11 +2404,10 @@
=end original
-Don't think that you can get the address of a Perl variable
-when it is stored as an integer or double number! C<pack('P', $x)> will
-force the variable's internal representation to string, just as if you
-had written something like C<$x .= ''>.
-(TBT)
+整数や倍精度実数として保管されている Perl 変数のアドレスを取れるとは
+考えないでください!
+C<pack('P', $x)> は、ちょうど C<$x .= ''> のようなものを書いたのと同様に、
+変数の内部表現を文字列に強制します。
=back
@@ -2426,9 +2418,8 @@
=end original
-It's safe, however, to P- or p-pack a string literal,
+しかし、文字列リテラルを P またはor p で pack することは安全です;
なぜなら Perl は単に無名変数を割り当てるからです。
-(TBT)
=head1 Pack Recipes