質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Go

Go(golang)は、Googleで開発されたオープンソースのプログラミング言語です。

Q&A

解決済

1回答

392閲覧

Go言語でメソッドを持つ実体をスライスに追加する時の挙動について

Mild_Boss

総合スコア13

Go

Go(golang)は、Googleで開発されたオープンソースのプログラミング言語です。

0グッド

0クリップ

投稿2019/05/17 12:11

編集2019/05/17 15:37

前提

Go 言語のポインタレシーバに関する質問です。
他言語(C, Python, PHP)の経験はありますが、Go 言語は A Tour of Go を1周したくらいの知識です。

質問

以下のように、ポインタレシーバを受け取りクロージャーを返すメソッド say_closure があります。
これを、関数のスライスに append で格納していく処理を想定しています。

その際に、クロージャーを直接格納する以下の場合は想定通りの動きになります。

Go

1// https://play.golang.org/p/tUH74eXCG92 2package main 3 4import ( 5 "fmt" 6) 7 8type T struct { 9 N string 10} 11 12func (s *T) say_closure() func() { 13 return func() { 14 fmt.Printf("%s\n", s.N) 15 } 16} 17 18func main() { 19 func_slice := []func(){} 20 21 func_slice = append(func_slice, (&T{"foo"}).say_closure()) 22 23 fmt.Println("--- foo append 前 ---") 24 func_slice[0]() // => "foo" 25 26 func_slice = append(func_slice, (&T{"bar"}).say_closure()) 27 28 fmt.Println("--- bar append 後 ---") 29 func_slice[0](); func_slice[1]() // => "foo" "bar" 30} 31

ここでは、func_slice[0] には T{"foo"} が、func_slice[1] には T{"bar"} が格納され、それぞれのクロージャーが適切に呼ばれています。

しかし、以下のように型 T の変数を中継する形で append を行うと、問題が発生します。

Go

1// https://play.golang.org/p/Ct7ZLMkfst0 2package main 3 4import ( 5 "fmt" 6) 7 8type T struct { 9 N string 10} 11 12func (s *T) say_closure() func() { 13 return func() { 14 fmt.Printf("%s\n", s.N) 15 } 16} 17 18func main() { 19 func_slice := []func(){} 20 var tmp T 21 22 tmp = T{"foo"} 23 func_slice = append(func_slice, tmp.say_closure()) 24 25 tmp = T{"bar"} 26 fmt.Println("--- tmp に代入後 ---") 27 func_slice[0]() // => "bar" 問題:この時点で foo が bar に置き換わっている 28 29 func_slice = append(func_slice, tmp.say_closure()) 30}

個人的には、こちらでも func_slice[0] には T{"foo"} が、func_slice[1] には T{"bar"} が格納されていてほしいのですが、そうはなりません。func_slice[0] も func_slice[1] にも T{"bar"} が格納されています。

スライスの第0要素には T{"foo"}.say_closure() の返り値の関数が入っていたはずなのですが、tmp に T{"bar"} を代入した時点でスライスの第0要素の参照先が変わっていることに困惑しています。
なぜなら、append に指定しているのは tmp そのものではなく tmp.say_closure() なので、say_closure の返り値が格納されているのが自然だと思っているからです。

どこの参照先がスライスに代入され、どこでその参照先が変わるのかが全くイメージできていないため、この問題をどう解釈すればいいのかすら分からない状態です。

いくつかの Go の仕様が重なっている問題かもしれませんが、解説やご指摘頂けると幸いです。
(ドキュメントや書籍のここを読めというコメントでも構いません。)

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

スライス云々は関係なく、構造体の値と構造体メソッドのレシーバの関係でおこりうる現象です。

これはtmpが構造体の値であることに対し、say_closureメソッドのレシーバがポインタである時におこりえます。
以下のようにポインタの表示をしてみれば一目瞭然です。

https://play.golang.org/p/igptr8rCbV7

go

1package main 2 3import ( 4 "fmt" 5) 6 7type T struct { 8 N string 9} 10 11func (s *T) say_closure() func() { 12 return func() { 13 fmt.Printf("%s(%p)\n", s.N, s) 14 } 15} 16 17func main() { 18 var tmp T 19 20 tmp = T{"foo"} 21 fmt.Printf("%s(%p)\n", tmp.N, &tmp) 22 fn := tmp.say_closure() 23 fn() 24 tmp = T{"bar"} 25 fn() 26}

出力は以下のようになされ、tmpのアドレスとfooとbarのレシーバポインタとで3つとも同じ値になります。

foo(0x40c128) foo(0x40c128) bar(0x40c128)

つまり、say_closureのレシーバ「s」ポインタの指し示す先はtmp変数なので
tmp変数をいくら上書きしてもsay_closureの挙動は現在のtmp変数の内容に依存した結果になります。

Goでは基本的には

  • レシーバをポインタ型にした場合、構造体を扱う側もポインタ型変数で扱います
  • レシーバを値型にした場合、構造体を扱う側も値型変数で扱います

細かい挙動を把握した人が混在で取り扱うのは禁止はされていませんが熟練者向けです。
また、いくつかのメソッドでレシーバの型にポインタ型と値型を混在させるとその構造体はインターフェース型には変換できなくなります。

投稿2019/05/20 01:47

編集2019/05/20 12:21
nobonobo

総合スコア3367

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Mild_Boss

2019/05/24 06:35

ポインタを表示するコード例で問題点がはっきりしました。 スライスなど他のことに目が言ってました。 後半の指針の通り、Go に慣れるまでは値型とポインタ型の変数・レシーバを混在させることは控えようと思います。 どうもありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問