Goメソッドで "this"を値渡しするとパフォーマンスが低下しますか？

Question

私はC++開発の9年後にGoを探検しています。 C++では、パフォーマンスの不利益のために、組み込み型の変数を除いて、関数の引数を値で渡すのは悪い習慣です。引数のすべてのフィールドがコピーされ、ほとんどの場合、非常にコストのかかる操作になります。

Goではこれは当てはまりますか？メソッドに "const"セマンティックを割り当てるためだけに、値で "this"を渡すのは非常に高額に見えます。最初の変更前に変数がコピーされないようにするには、コンパイラをスマートにしてください。 C/C++のようにGoのアンチパターンを値で渡すのはなぜですか？

Answer 1

Goのthisはreceiverと呼ばれます。はい、非ポインタ受信機のみを使用して "const"セマンティクスをエミュレートするのは非常に高価です。しかし、良い理由から "const"修飾子を削除しました。したがって、不要なコピーを犠牲にして、特定の言語設計の決定を引き継ぐことは、おそらく良い考えではありません。

「this」と「self」と「receiver」の用語の違いは、セマンティクスも異なることを意味します。 IIRCでは、他のいくつかの言語では "this"または "self"の値を変更できませんが、Goではレシーバは別の関数パラメータ（実際にはコンパイラの観点からは最初の関数パラメータ）です。

これは、受信者変数の名前がthisまたはselfであるという記述方法を推奨しない理由です。他の言語に慣れた人にとっては誤解を招きます。私はあなたのC++の知識が（値によって構造体を渡す）関数の引数として高価であるかについてのゴーに罰金翻訳しますと言うでしょう

func (n *node) walk(f func(*node)) { 
     for n != nil { 
       f(n) 
       n = n.next 
     } 
} 

Answer 2

と何ISN：

うまくいけば、アイデアを示す完全に作らアップの例't（組み込み型、例えばint）。

大きな違いは、リファレンスタイプのスライスmapとchannelです。これらは、値渡しのように見えますが（ポインタを使用する必要はありません）、実際には参照渡しとなりますので、一般的にはスライス、マップ、またはチャネルへのポインタを使用しないでください。

も特別です。これらは、フードの参照型ですが、不変でもあり、直接渡します。

thisという特定のケースや、Goで呼ばれる受信機については、同じルールが適用されます（C++とは異なり、組み込みタイプを受信機として使用できることに注意してください）。コンパイラが十分スマートではないと思いますコピーを避けるために、大きな構造体のポインタを使用してください。

Answer 3

他の回答は良いですが、私の意見では、いくつかの情報がありません。移動中

レシーバは、以下のcodeによって示されるように、単なる糖衣構文です：

package main 

import "fmt" 

type Something struct { 
    Value int 
} 

func (s *Something) ChangeValue(n int) { 
    s.Value = n 
} 

func main() { 
    o := new(Something)    // o is of type *Something 
    fmt.Println(o.Value)   // Prints 0 
    o.ChangeValue(8)    // Changes o.Value to 8 
    fmt.Println(o.Value)   // Prints 8 
    (*Something).ChangeValue(o, 16) // Same as calling o.ChangeValue(16) 
    fmt.Println(o.Value)   // Prints 16 
} 

これに基づき、ChangeValueの受信機はタイプSomethingの値の代わりにポインタだった場合に何が起こるかを検討しますone ...

そうですよ！この方法で実際にoのValueフィールドを変異させることはできません。ほとんどの場合、カプセル化を行うためにポインタ受信機を使用します。

Answer 4

受信機のサイズによって異なります。受信者が数十バイト未満の場合は、ポインタを渡した場合に必要となるポインタ追い越し（余分なメモリアクセス）よりも実際には安いかもしれません。また、ポインタを使用すると、構造体がヒープ上に割り当てられる可能性が高くなり、ガベージコレクタに負担がかかります。

Goでは、コピーは常にバイトごとのコピーであるため、コストは構造体のサイズにのみ依存します。 C++では、コピーコンストラクタが呼び出される可能性があります。

本当に大きなオブジェクトを除いて、メソッドのセマンティクスと他のAPIとの一貫性に基づいて、どんな種類の受信機でも最も合理的なものを使用してください。