n=n++;

Last-modified: 2009-05-08 (金) 19:07:30

n = n++;†

まえおき†

n = n++; という代入文の話をM先生から聞いて、気になったので調べてみた。

実はM先生が言っておられたのは以下のようなコードのことで、これなら別に問題ない。（少なくとも解釈には困らない。）

class Some {
    int n;
    void foo(int n) {
        this.n = n++;
    }
}

↑

本題†

文字通り n = n++; という代入文だとどうなるの? というのが今回の問題。つまり、

int n = 0;
n = n++;

というコードを考えると、

式 n++ の値は 0 なので、代入演算によって n に 0 が代入される。
++演算子により、n がインクリメントされる。

という2つの処理が行われるはずだけれども、順序次第で結果は変わる。1→2なら実行後の n は1になるし、2→1なら n は0になる。

n = n + 1; という書き方と n++; という書き方を習った人が、こんがらがって(?) n = n++; と書いた、という例は何回か見たことある。そのとき使ってた Microsoft C/C++ Compiler だと、特に警告はなく、結果は n++; と書いたのと同じ（n がインクリメントされる）だった。（書いた人たちもインクリメントのつもりで書いているので、間違いに気づかなかった。）

↑

K&R†

K&R*1には、悪い例として a[i] = i++; が出てくる（a[i] の i の値は処理系依存）。なら、n = n++; も悪い例なんでしょうね? たぶん。

↑

GCC†

GCCだとどうか? というと、結果 n がインクリメントされるのは同じ（試したのは powerpc-apple-darwin8-gcc-4.0.1 と i386-redhat-linux-gcc-4.1.2）。

で、-Wsequence-pointオプションを付けると、

warning: operation on 'n' may be undefined

という警告が出るようになる（カシコイ）。

manページの -Wsequence-point の項を見ると、

(略)

Examples of code with undefined behavior are "a = a++;", "a[n] = b[n++]" and "a[i++] = i;". Some more complicated cases are not diagnosed by this option, and it may give an occasional false positive result, but in general it has been found fairly effective at detecting this sort of problem in programs.

(略)

ということで、n = n++; は undefined behavior なコードとのこと。

↑

Java†

じゃあ Java は? というと、これがエラーじゃないのだな。（意外じゃない? そう?）

int n = 0;
n = n++;
System.out.println("n = " + n);

というコードはちゃんとコンパイルできる。で、結果は n = 0 と表示される。つまり、上のほうに書いた2→1の順、ということに。

↑

言語仕様†

Java言語仕様 *2ではどうなってんの? と見てみると、「評価順序」という節(§15.7)にごちゃごちゃ書いてある。

n = n++; の解釈は「Evaluate Operands before Operation」(§15.7.2)の原則に従えばよいのでしょうね? つまり、代入演算より先に右辺が完全に評価される(fully evaluated)、と。「完全に評価される」って何? と言うと、§15.7.1の本文から察するに、副作用も全部実行される、という意味みたい。

「n = a++; はよくて n = n++; はだめ」とか言い出すと規則が複雑になるし、代わりに意味論の自由度をなくしとけば（run anywhere的には）不都合ないでしょ? てことか。

↑

と言うことは†

じゃあ a[i] = i++; や a[i++] = i; もokなわけね? ということで実験。

int[] a = new int[] { 0, 0, 0, 0, 0 };
int i = 1;
a[i]   = i++;  // (*1)
a[i++] = i;    // (*2)
for (int j = 0; j &lt; a.length; j++) {
    System.out.print(a[j] + " ");
}
System.out.println();

問題なくコンパイルできる。結果は 0 1 3 0 0。

= についても「Evaluate Left-Hand Operand First」(§15.7.1)の原則で、左辺を先に評価するわけですな? 上のコードの(*1)では a[1] に 1 が代入され、i は 2 になる。(*2)では a[2] にインクリメント後の i が代入される。

↑

おまけの実験†

この言語仕様書とか“The Java Programming Language*3”とかよく見ると、n = n++; よりえげつない例もいろいろと…。

下記はThe Java Programming Languageの§9.2.1の例。

int i = 16;
System.out.println(++i + " " + i++ + " " + i);

…はいはい、Java的にはokなんでしょ? よくわかりマシタ。(-.-) ちなみに 17 17 18 と表示されるのが正解。

もちろん C では処理系依存のはず…、ということで試してみる。文字列連結演算子がないのでそっくりにはできないが、下のようなコードだと…。

int i = 16;
printf("%d %d %d\n", ++i, i++, i);

K&Rにも似た例が「悪い例」として挙がっている（引数の評価順序は処理系依存）。実行結果は以下の通り。

powerpc-apple-darwin8-gcc-4.0.1	`18 17 18`
i386-redhat-linux-gcc-4.1.2	`18 16 18`

2番目だけ小さい値になるのがちょっと意外。

今度は sprintf と strcat を組み合わせて文字列連結演算を模倣してみると…（下のコード）。

#include &lt;stdio.h&gt;
#include &lt;string.h&gt;
char *tostr(int i) {
    static char buf[3][256];
    static int bufc = 0;
    sprintf(buf[bufc], "%d ", i);
    return buf[bufc++];
}
int main() {
    int n = 16;
    printf("%s\n", strcat(strcat(tostr(++n), tostr(n++)), tostr(n)));
    return 0;
}

結果は以下の通り。powerpcは左引数優先、i386は右引数優先、のような結果。

powerpc-apple-darwin8-gcc-4.0.1	`17 17 18`
i386-redhat-linux-gcc-4.1.2	`18 16 16`

↑

結論†

n = n++; という文は、

Javaでは正しい文（でも n の値は変化しないので無意味）
Cでは振る舞いは処理系依存（でもインクリメントされる場合が多い?）
GCC 4 で -Wall をつければ警告が表示される

*1 カーニハン, リッチー: プログラミング言語C, 第2版, 石田訳, p.66, 共立出版, 1989.
*2 The Java Language Specification, Third Edition, http://java.sun.com/docs/books/jls/
*3 K.Arnold, J.Gosling, and D.Holmes: The Java Programming Language, Fourth Edition, Addison-Wesley, 2006.