List of Pointer [text.Baldanders.info]

ポインタが指し示す意味を考える

2020-12-26T06:08:29+00:00

以下の記事がちょっと面白かったのでこの記事でも試してみる。

なお，大元の Should I Use a Pointer instead of a Copy of my Struct? が書かれたのは2019年5月で，おそらく Go のバージョンも 1.12 あたりだと思うので，その辺を考慮して読むといいだろう。ちなみに A Journey With Go は Go の内部動作について割と詳しく解説されていてオススメの読み物である。

ヒープのコスト

起点 (トリガー) はこの構造体型。

type S struct {
   a, b, c int64
   d, e, f string
   g, h, i float64
}

via Should I Use a Pointer instead of a Copy of my Struct?

そして，この型のインスタンスを生成する（実質的な）構築子を2つ用意する。

func byCopy() S {
   return S{
      a: 1, b: 1, c: 1,
      e: "foo", f: "foo",
      g: 1.0, h: 1.0, i: 1.0,
   }
}

func byPointer() *S {
   return &S{
      a: 1, b: 1, c: 1,
      e: "foo", f: "foo",
      g: 1.0, h: 1.0, i: 1.0,
   }
}

via Should I Use a Pointer instead of a Copy of my Struct?

2つの関数はいずれもリテラル表現で指定された内容のインスタンスを返すが， byCopy() 関数は値を byPointer() 関数はポインタを返すという違いがある。また byCopy() 関数ではインスタンスをスタック上に置くが byPointer() 関数ではインスタンスをヒープ上に生成する¹。

これらの関数の呼び出しコストを計測するベンチマーク・テストは以下の通り。

func BenchmarkMemoryStack(b *testing.B) {
    var s S
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        s = byCopy()
    }
    b.StopTimer()
    _ = fmt.Sprintf("%v", s.a)
}

func BenchmarkMemoryHeap(b *testing.B) {
    var s *S
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        s = byPointer()
    }
    b.StopTimer()
    _ = fmt.Sprintf("%v", s.a)
}

元記事のコードでは GC (Garbage Collection) の挙動を検証するために色々と仕込んでいるが，今回はコストだけを測ればいいので単純な構成にしてある。

結果はこんな感じ。

$ go test ./... -bench Memory -benchmem
goos: linux
goarch: amd64
pkg: pointer
BenchmarkMemoryStack-4       132169167             9.04 ns/op           0 B/op           0 allocs/op
BenchmarkMemoryHeap-4        15257716            71.6 ns/op          96 B/op           1 allocs/op
PASS
ok      pointer    3.233s

まぁ，元記事とだいたい同じ結果かな。見にくいので表にまとめておこう。

関数名	実行時間 (ナノ秒)	Alloc サイズ	Alloc 回数
`BenchmarkMemoryStack`	9.0	0	0
`BenchmarkMemoryHeap`	71.6	96	1

言うまでもないが s = byCopy() は代入文で Go では代入時に必ずコピーが発生する。ただし s = byCopy() がインスタンス自体のコピーなのに対し s = byPointer() ではポインタ値のみコピーされる。

つまり上の結果はヒープ領域の割当と解放にかかる（GC を含む）時間コスト（の平均）がインスタンスのコピーよりもかなり大きいことを示している。それでも（GC のオーバーヘッドを含めても）平均で100ナノ秒未満で済んでいるなら十分に優秀だと思うけどね。

元記事でも解説されているが Go の GC は独立の goroutine で駆動するため，アーキテクチャ² や使用するコア数の影響を大きく受ける。 GC を含めてシビアな評価が必要なのであれば，その辺の環境を含めて考えるべきだろう。

コピーのコスト（2020-12-27 訂正）

元記事には続きがある。さきほどの構造体 S に対し

//go:noinline
func (s S) stack(s1 S) {}

//go:noinline
func (s *S) heap(s1 *S) {}

via Should I Use a Pointer instead of a Copy of my Struct?

というメソッドを用意してベンチマークテストを以下のように書き直す³。

func BenchmarkMemoryStack(b *testing.B) {
    var s S
    var s1 S

    s = byCopy()
    s1 = byCopy()
    for i := 0; i < b.N; i++ {
        for i := 0; i < 1000000; i++ {
            s.stack(s1)
        }
    }
}

func BenchmarkMemoryHeap(b *testing.B) {
    var s *S
    var s1 *S

    s = byPointer()
    s1 = byPointer()
    for i := 0; i < b.N; i++ {
        for i := 0; i < 1000000; i++ {
            s.heap(s1)
        }
    }
}

via Should I Use a Pointer instead of a Copy of my Struct?

Go の関数引数は値渡し（call by value）なので引数として渡す時点でコピーが発生するが s.heap(s1) はポインタ値がコピーされるだけなので，単純に考えれば s.stack(s1) のほうがコストが大きいように思える。

実際にこれを実行すると

$ go test ./... -bench Memory -benchmem
goos: linux
goarch: amd64
pkg: pointer
BenchmarkMemoryStack-4   	     174	   6794688 ns/op	       0 B/op	       0 allocs/op
BenchmarkMemoryHeap-4    	     514	   2263913 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	pointer	3.285s

てな感じになる。

んー。元記事とは少し違うが，3倍程度の差があるかな。これも表にまとめておこう。

関数名	実行時間 (μ秒)	Alloc サイズ	Alloc 回数
`BenchmarkMemoryStack`	6.8	0	0
`BenchmarkMemoryHeap`	2.3	0	0

なお //go:noinline ディレクティブがないと最適化されてしまいほとんど差がなくなるようだ。

Interface のコスト

ではここで元記事にはなかったテストを考えてみよう。

構造体 S に以下のメソッドを追加し

func (s S) ValueA() int64 { return s.a }

このメソッドを有効にする interface 型

type IS interface {
    ValueA() int64
}

と，この型を返す構築子

func byInterface() IS {
    return S{
        a: 1, b: 1, c: 1,
        e: "foo", f: "foo",
        g: 1.0, h: 1.0, i: 1.0,
    }
}

を定義する。この構築子を使ったベンチマークテストも書いておこう。

func BenchmarkMemoryBox(b *testing.B) {
    var s IS
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        s = byInterface()
    }
    b.StopTimer()
    _ = fmt.Sprintf("%v", s.ValueA())
}

これを最初のベンチマークテストと比較してみる。結果はこんな感じ。

$ go test ./... -bench Memory -benchmem
goos: linux
goarch: amd64
pkg: pointer
BenchmarkMemoryStack-4       132085750             9.08 ns/op           0 B/op           0 allocs/op
BenchmarkMemoryHeap-4        15357787            70.0 ns/op          96 B/op           1 allocs/op
BenchmarkMemoryBox-4         14711439            76.0 ns/op          96 B/op           1 allocs/op
PASS
ok      pointer    4.392s

表にまとめておこう。

関数名	実行時間 (ナノ秒)	Alloc サイズ	Alloc 回数
`BenchmarkMemoryStack`	9.1	0	0
`BenchmarkMemoryHeap`	70.0	96	1
`BenchmarkMemoryBox`	76.0	96	1

時間コストについて byCopy() 関数と byPointer() 関数を足したよりちょっと小さい，って感じだろうか。

Interface 型の機能とはボックス化（boxing）である。ボックス化されたインスタンスは必ずヒープ領域に置かれる。その意味で byPointer() 関数と byInterface() 関数がメモリ管理で似たような挙動になるのは納得できるのではないだろうか。

ヒープを恐れるな

ヒープメモリ操作が高コストなのは汎用 OS 下で動くアプリケーションであれば自明であり，そこに GC のオーバーヘッドが加わるのだから，そりゃあもう「あたり前田のクラッカー」という奴である。

私のようなロートル世代ではヒープ管理は（可能であれば）忌避したい代物だった。上述したように操作自体が高コストなのに加えて割当と解放を漏れなく矛盾なく記述しきらなければならないのだから面倒くさいことこの上ない。

Go では goroutine や interface 型を使った抽象化と引き換えに並列処理やヒープ管理などの面倒くさい部分をランタイム・モジュールに丸投げする。しかもその「面倒くさい部分」を細かく制御できず，これが Go プログラミングにおける重要なトレードオフとなっているのである。

もしヒープ管理をテッペンから見下ろして完全掌握したいと考えるのなら GC は邪魔なだけだし，そもそも Go で書くインセンティブがない。それこそ近ごろ流行りの Rust とかで書くべきだろう。

今回の記事のような話を知識として知っておくのはいいことだと思うが，設計上の重要なポイントではない（むしろチューニングの話だ）。ポインタを「概念」で捉えることができれば「ポインタが指し示す意味」について深く考察できるようになる。それこそが本来の「プログラム設計」というやつである。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

SAVED. ／ Be mine!: 坂本　真綾 (メインアーティスト); FlyingDog 2014-02-05 (Release 2014-02-05); MP3 ダウンロード; B00HY73M16 (ASIN); 評価

「世界征服〜謀略のズヴィズダー〜」OP曲。万能感溢れるノリのいい曲である（笑）

reviewed by Spiegel on 2020-12-26 (powered by PA-APIv5)

よく勘違いされるが（というか私も最初の頃は勘違いしていたが）リテラル表現で &S{ ... } と記述する場合は，どっかに固定のインスタンスがあって，その固定インスタンスへのポインタを示しているのではなく，暗黙的にヒープ上にインスタンスを生成してリテラルの内容で初期化している。つまり &S{} は new(S) と等価である。むしろリテラルで初期値を指定できる分だけ new() 関数より簡潔で優れている。詳しくは『プログラミング言語Go』の4.4.1章を参照のこと。これを知ってから組み込みの new() 関数はほとんど使わなくなった（笑） ↩︎
最近の goroutine はプリエンプティブ・マルチタスクが可能になったが，アーキテクチャによっては対応していない場合がある。 ↩︎
元記事では //go:noinline ディレクティブがなかったが，これがないと最適化されしまうため，コードを変更している。 ↩︎

For-Range 構文の話

2019-05-17T15:44:20+00:00

今回は小ネタでお送りします。

つか，以下の記事

Big Sky :: Go のポインタの躓きやすい点

の後半部分が何を問題にしているのか分からずしばらく悩んでしまった。頭が悪くてゴメンペコン。

まず前提として Go 言語において「参照」のことは忘れよう。見た目は参照ぽく振る舞う場合もあるしこのブログでも比喩表現として参照という言葉をよく使うが，言語仕様としては Go 言語に「参照」は存在しない。 Go 言語のインスタンスを表すものは「値」と「アドレッシング」であり，その「アドレッシング」の表現として（C 言語ではお馴染みの）ポインタを使うわけだ¹。したがって，コーディングを行う際はインスタンスの値とアドレッシングを常に頭に入れながら進めるとハマりにくい。分からないならコードを書いてみればいいのだ。

では，最初に紹介した記事を参考に実際にコードを書いてみようか。

まず，以下のような型 A を考える。

type A struct {
    N string
}

func (a *A) GenFunc() func() {
    return func() {
        fmt.Printf("%s : %p\n", a.N, a)
    }
}

A.GenFunc() 関数は型 A の内容を標準出力に出力する関数を返す。 Method receiver が A ではなく *A とポインタ型になっているのがポイントである（洒落ちゃったてへぺろ）。

これを使って以下のコードを書いてみる。

package main

import "fmt"

type A struct {
    N string
}

func (a *A) GenFunc() func() {
    return func() {
        fmt.Printf("%s : %p\n", a.N, a)
    }
}

func main() {
    as := []A{
        {"foo"},
        {"bar"},
    }
    for i := 0; i < len(as); i++ {
        fmt.Printf("instance: %s : %p\n", as[i].N, &as[i])
        as[i].GenFunc()()
    }
}

このコードを実行すると

instance: foo : 0x40a0e0
foo : 0x40a0e0
instance: bar : 0x40a0e8
bar : 0x40a0e8

などと出力される。 GenFunc() メソッドを呼び出す際に method receiver としての as[i] の型が暗黙的に変換されていることに注意してほしい。ここまでは OK かな。

では for-range 構文を使うとどうなるか。試しに main 関数に for-range の制御ブロックを追加して比較してみよう。

func main() {
    as := []A{
        {"foo"},
        {"bar"},
    }
    for i := 0; i < len(as); i++ {
        fmt.Printf("instance: %s : %p\n", as[i].N, &as[i])
        as[i].GenFunc()()
    }
    fmt.Println()
    for _ , a := range as {
        fmt.Printf("instance: %s : %p\n", a.N, &a)
        a.GenFunc()()
    }
}

これを実行するとこうなる。

instance: foo : 0x40a0e0
foo : 0x40a0e0
instance: bar : 0x40a0e8
bar : 0x40a0e8

instance: foo : 0x40c160
foo : 0x40c160
instance: bar : 0x40c160
bar : 0x40c160

ポインタ値からインスタンス a はインスタンス as[i] そのものではないことが分かる。しかも a は for-range ループの中で使い回されていていることも分かる。

つまり上の for-range 構文は

for i, a := 0, as[0]; i < len(as); i, a = i+1, as[i+1] {
    fmt.Printf("instance: %s : %p\n", a.N, &a)
    a.GenFunc()()
}

と実質的に同じなのだ²。

ここまで来れば

func main() {
    as := []A{
        {"foo"},
        {"bar"},
    }
    fs := []func(){}
    for _, a := range as {
        fs = append(fs, a.GenFunc())
    }
    for _, f := range fs {
        f()
    }
}

の実行結果がどうなるか容易に想像がつくだろう。以下の通りである。

bar : 0x40c128
bar : 0x40c128

つまり fs に格納される関数は全て前半の for-range の中のインスタンス a に帰属するメソッドであり，そのインスタンス a の値は for-range ループの中で上書きされているのである。

じゃあどうすればいいかというと，一番簡単で場当たりな対処としては for-range ループの中でインスタンス a のコピーを作ればよい。

func main() {
    as := []A{
        {"foo"},
        {"bar"},
    }
    fs := []func(){}
    for _ , a := range as {
        aa := a //create copy instance
        fs = append(fs, aa.GenFunc())
    }
    for _ , f := range fs {
        f()
    }
}

これで実行結果は

foo : 0x40c128
bar : 0x40c140

となる。あるいは最初から素直に

func main() {
    as := []A{
        {"foo"},
        {"bar"},
    }
    fs := []func(){}
    for i := 0; i < len(as); i++ {
        fs = append(fs, as[i].GenFunc())
    }
    for _ , f := range fs {
        f()
    }
}

とすれば要らんコピーも発生せず，実行結果も

foo : 0x40a0e0
bar : 0x40a0e8

となる。

最初に紹介した記事にも書かれている通り，インスタンスの値とポインタを混ぜるから危険なのであって混ぜなければ大丈夫（笑）

ブックマーク

関数とポインタ

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

プログラミング言語C 第2版 ANSI規格準拠: B.W. カーニハン (著), D.M. リッチー (著), 石田晴久 (翻訳); 共立出版 1989-06-15; 単行本; 4320026926 (ASIN), 9784320026926 (EAN), 4320026926 (ISBN); 評価

通称 “K&R”。その筋の人々には「バイブル」と呼ばれる名著（当時は）。

reviewed by Spiegel on 2018-12-07 (powered by PA-APIv5)

参照とポインタの決定的な違いは，参照は「機能」だがポインタは「値」である，という点であろう。値なのでポインタ自身をインスタンスとして表現し得るし「ポンタへのポインタ」みたいな記述もできる。この辺の感覚が掴めないと苦労するかもしれない。大昔の C 言語が全盛だった頃もポインタで躓く人は割といたからなぁ。 ↩︎
厳密には違う。つか，このコードを実際に書いて動かしてみれば分かるが “index out of range” の panic を吐いて落ちる。理由は各自で考えてみよう（笑） ↩︎

関数とポインタ

2016-03-29T13:16:41+00:00

いまさらな内容なのだが覚え書きとして記しておく。

Go 言語における Calling Sequence

まずは簡単な足し算の関数を定義してみる。

func add(x int, y int) int {
    return x + y
}

add に続く括弧内が引数を定義していて，括弧の後ろの int は返り値の型¹ を示している。 add() 関数を呼び出すには以下のように記述する。

package main

import "fmt"

func add(x int, y int) int {
    return x + y
}

func main() {
    ans := add(42, 13)
    fmt.Println(ans)
}

x と y は同じ int 型なので以下のように記述することもできる。

func add(x, y int) int {
    return x + y
}

返り値を組（tuple）で定義することもできる。

func split(sum int) (int, int) {
    x = sum * 4 / 9
    y = sum - x
    return x, y
}

また返り値には，以下に示すように，あらかじめ名前をつけることもできる。

func add(x, y int) (ans int) {
    ans = x + y
    return
}

最後の return がないとコンパイル・エラーになるので注意。この書き方は defer 構文と組み合わせるときに威力を発揮する。

package main

import "fmt"

func main() {
    err := r()
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("Normal End.")
    }
}

func r() (err error) {
    defer func() {
        if rec := recover(); rec != nil {
            err = fmt.Errorf("Recovered from: %v", rec)
        }
    }()

    f()
    err = nil
    return
}

func f() {
    panic("Panic!")
}

このコード² では r() 関数内で panic を捕まえ，返り値の err に値をセットしなおしている。

Go 言語の引数は「値渡し」

Go 言語の引数は基本的に「値渡し（call by value）」である。たとえば先程の足し算を

func add(x, y int) int {
    x += y
    return x
}

と定義した場合でも

package main

import "fmt"

func add(x, y int) int {
    x += y
    return x
}

func main() {
    x := 42
    y := 13
    ans := add(x, y)
    fmt.Printf("%d + %d = %d\n", x, y, ans) //output: 42 + 13 = 55
}

呼び出し元で add() 関数の引数に渡した instance は関数実行後も変化しない。このため引数の値渡しは thread safe なコードに向いている。ただし関数呼び出し時に instance の値が常にコピーされるため³，サイズの大きな instance の場合は呼び出し時のコストが高くなる。引数の値渡しが有利な例としては value object を構成する場合などが考えられる。

Instance の値ではなく実体を渡したいときがある。この場合はポインタを使う。つまり instance へのポインタ値を渡すのである。

package main

import "fmt"

func add(x, y *int) int {
    *x += *y
    return *x
}

func main() {
    x := 42
    y := 13
    ans := add(&x, &y)
    fmt.Printf("%d + %d = %d\n", x, y, ans) //output: 55 + 13 = 55
}

このコードでは add() 関数実行後の x の値が変更されている。このように instance へのポインタ値を引数として渡すやり方をこの記事では，通常の「値渡し」とは区別して，「ポインタ渡し」と呼ぶことにする⁴。

内部状態を持つ instance を引数に指定する場合はポインタ渡しにする必要がある。しかし引数をポインタ渡しにすると関数実行が thread safe でなくなる可能性がある。また引数の値が nil の場合も考慮する必要がある。

ちなみに Go 言語では通常の方法ではポインタ演算ができない。たとえば，ついうっかり

func add(x, y *int) int {
    x += y
    return *x
}

とか書いてしまっても

invalid operation: x += y (operator + not defined on pointer)

とコンパイル・エラーになる。したがって通常は「Go 言語のポインタは nullable 参照⁵ と同じ」と考えてよい。

なお，ポインタ演算が必要な場合は unsafe パッケージを使う。

Slice, Map, Channel は参照渡しのように振る舞う

slice, map, channel は組み込み型だが内部状態を持つ⁶。これらの型の instance を引数に渡す場合は参照渡しのように振る舞う⁷。

package main

import "fmt"

func setItem(ary map[int]int, index, item int) {
    ary[index] = item
}

func main() {
    ary := map[int]int{0: 0}
    fmt.Println(ary) //output: map[0:0]
    setItem(ary, 0, 1)
    fmt.Println(ary) //output: map[0:1]
    setItem(ary, 10, 10)
    fmt.Println(ary) //output: map[0:1 10:10]
}

ただし固定の配列や string 型⁸ の instance は「値」として振る舞うため⁹，引数に指定した場合も値渡しのように振る舞う。 slice とは挙動が異なるためテキトーなコードを書いていると混乱しやすい。

package main

import "fmt"

func setItem(ary [4]int, index, item int) {
    ary[index] = item
}

func main() {
    ary := [4]int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    setItem(ary, 1, 10)
    fmt.Println(ary) //output: [0 1 2 3]
    ary[2] = 200
    fmt.Println(ary) //output: [0 1 200 3]
}

固定配列や string 型をポインタ渡しすることはできる。もっとも string 型の instance は「不変（immutable）」なのでポインタ渡しが必要な局面はほとんど無いと思うが¹⁰。

固定配列をポインタ渡しする例は以下の通り。

package main

import "fmt"

func setItem(ary *[4]int, index, item int) {
    (*ary)[index] = item
}

func main() {
    ary := [4]int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    setItem(&ary, 1, 10)
    fmt.Println(ary) //output: [0 10 2 3]
}

固定配列は不変ではないが，配列を操作するのであれば固定配列ではなく slice のほうが扱いやすい。たとえば上のコードでは slc := ary[:] といった感じにキャストするか最初から ary := []int{0, 1, 2, 3} と初期化すれば slice として扱える。

Method Receiver

ある型に関数を関連付ける場合は method receiver を使う。

type Vertex struct {
    X int
    Y int
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

(v Vertex) の部分が method receiver である。 Add() 関数を呼び出すには以下のように記述する。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := Vertex{X: 1, Y: 2}
    vv := v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v)  //output: X = 1, Y = 2
    fmt.Println(vv) //output: X = 4, Y = 6
}

関数の calling sequence としては v.Add(dv) と Vertex.Add(v, dv) は等価である。つまり v は Add() 関数の0番目の引数として振る舞い，値渡しでセットされる。

Method receiver の型をポインタ型にすればポインタ渡しにできる。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v * Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := &Vertex{X: 1, Y: 2}
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: X = 4, Y = 6
}

この場合も calling sequence としては v.Add(dv) と (*Vertex).Add(v, dv) は等価である。

Method Receiver の暗黙的変換

Method receiver を値にした場合，呼び出し元の instance がポインタ型であっても暗黙的にコピーが発生し値渡しに変換される。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := &Vertex{X: 1, Y: 2} //pointer
    vv := v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v)  //output: X = 1, Y = 2
    fmt.Println(vv) //output: X = 4, Y = 6
}

Method receiver をポインタにした場合も，やはり暗黙的にポインタ渡しに変換される。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v *Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := Vertex{X: 1, Y: 2} //not pointer
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: X = 4, Y = 6
}

Method Receiver の値が nil の場合

Method receiver の値が nil の場合はどうなるか。まずは値渡しの場合。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := (*Vertex)(nil) //nil
    vv := v.Add(Vertex{X: 3, Y: 4}) //panic!
    fmt.Println(v)
    fmt.Println(vv)
}

この場合は Add() 関数呼び出し時に panic になる。

panic: runtime error: invalid memory address or nil pointer dereference

まぁこれは分かりやすいよね。ではポインタ渡しの場合はどうなるか。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v *Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := (*Vertex)(nil) //nil
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: <nil>
}

実は Add() 関数呼び出し時点では panic にはならない。上のコードでは v に nil が渡される。したがって Add() 関数内の条件文を削除すると

func (v *Vertex) Add(dv Vertex) {
    v.X += dv.X //panic!
    v.Y += dv.Y
}

v 内の要素を参照しようとしたところで panic になる。 Method receiver をポインタ渡しにする場合は nil 値に注意する必要がある。

for-range 構文も値渡し

余談だが for-range 構文も値渡し（つまりコピーが発生する）ので注意が必要である。たとえば以下のコードで

package main

import "fmt"

func main() {
    ary := []int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    for _, item := range ary {
        item += 10
    }
    fmt.Println(ary) //output: [0 1 2 3]
}

for-range 構文内の item は ary 内の要素を指すのではなく要素のコピーである。したがって item を操作しても ary には影響しない。 ary 内の要素を操作するのであれば素朴に

package main

import "fmt"

func main() {
    ary := []int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    for i := 0; i < len(ary); i++ {
        ary[i] += 10
    }
    fmt.Println(ary) //output: [10 11 12 13]
}

とするしかない。

ブックマーク

型については「Go 言語における「オブジェクト」」を参照のこと。 ↩︎
このコードについては「エラー・ハンドリングについて」で解説している。ちなみに panic を潰して error を返すのはエラー・ハンドリングとしては推奨できない。 ↩︎
値がどこにコピーされるかは型によって異なる。 string 以外の基本型は値がスタックに積まれる。 string および基本型以外はヒープ領域に値がコピーされその参照（＝ポインタ）がスタックに積まれる。 ↩︎
以前は，「値渡し」に対置する言葉として「参照渡し（call by reference）」と書いていたが，最近は「もう参照渡しとは言わせない」とか言う原理主義者がいるそうで，言いがかりに巻き込まれないよう「ポインタ渡し」と言い回しを変えることにした。やれやれ。 ↩︎
nullable 参照は「null を許容する参照」くらいの意味。 Go 言語なら nil 値。 Go 言語は「null 安全（null safty）」ではないので null 参照（＝無効な参照）の始末について instance を参照する側が責務を負うことになる。（参考：「null 安全」について） ↩︎
slice, map, channel は内部状態を持つため new() 関数ではなく make() 関数を使う。 ↩︎
詳しくは「配列と Slice」および「Map の話」を参照のこと。 ↩︎
string 型の実体は []byte 型である。 ↩︎
固定の配列や string 型の instance は nil 値を持たない「non-null 参照」と言える。ちなみに string 型のゼロ値は空文字列である。 ↩︎
このような需要としては文字列操作で「NULL 状態」が必要な場合であろう。たとえば DBMS にアクセスする場合は NULL 状態を扱う必要がある。なお Go 言語のコア・パッケージには database/sql があり NullString を使うことにより NULL 状態を扱える。このように NULL 状態を扱う必要がある場合は，直にポインタ操作するのではなく，何らかの value object を用意してカプセル化するほうが安全である。 ↩︎