blocks|key|702934|text|Go中的"this“被称为receiver。是的，使用非指针接收器来模拟"const“语义可能是非常昂贵的。但Go去掉了"const“修饰语是有充分理由的。因此，以不必要的复制为代价来接管特定的语言设计决策可能不是一个好主意-在任何比几个机器单词更大的情况下。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|702935|顺便说一句，"this“或"self”与"receiver“之间的术语差异意味着它也具有不同的语义。IIRC中，在其他语言中不能更改"this“或"self”的值，但在Go中，接收器只是另一个函数参数(实际上是从编译器的角度来看的第一个参数)。|702936|也就是说，这就是我不鼓励编写接收器变量命名为this或self的方法的原因。对于习惯于其他语言的人来说，这是一种误导。|style|CODE|702937|一个完全虚构的例子，希望能说明这个想法：|702938|func+(n+*node)+walk(f+func(*node))+{
++++++++for+n+!=+nil+{
++++++++++++++++f(n)
++++++++++++++++n+=+n.next
++++++++}
}|code-block|syntax|javascript|702939|entityMap|0|LINK|mutability|MUTABLE|url|http://golang.org/ref/spec#Method_declarations^0|D|8|0|0|0|M|4|R|4|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|13|8|@$A|14|B|15|H|I]|$A|16|B|17|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@]|C|$]]|$1|L|3|M|5|N|7|19|8|@]|9|@]|C|$O|P]]|$1|Q|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

"this" in Go is called a <a href="http://golang.org/ref/spec#Method_declarations" rel="nofollow">receiver</a>. Yes, it may be very expensive to use a non pointer receiver only to emulate a "const" semantics. But Go dropped the "const" modifier for good reasons. Thus, it's probably not a good idea to take over that specific language design decision at the cost of unnecessary copying - in the case of anything bigger than few machine words.

BTW, the terminology difference between "this" or "self" and "receiver" implies it has also different semantics. IIRC, one cannot change the value of "this" or "self" in some other languages, but in Go, the receiver is just another function parameter (actually the first one from the compiler's point of view).

That said, this is the reason I discourage writing methods in which the receiver variable is named <code>this</code> or <code>self</code>. It's misleading for people used to some other languages.

A completely made-up example illustrating hopefully the idea:

<pre><code>func (n *node) walk(f func(*node)) {
 for n != nil {
 f(n)
 n = n.next
 }
}
</code></pre>

blocks|key|4486142|text|我要说的是，你的C%2B%2B知识可以很好地转化为函数参数的开销(通过值传递结构)和开销(内置类型，例如整型)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4486143|主要的区别是引用类型，切片，map和channel。虽然它们看起来是通过值传递的(你不需要使用指针)，但实际上是通过引用传递的，所以通常不要使用指向切片、映射或通道的指针。|offset|length|style|CODE|4486144|string也很特殊-它们是幕后的引用类型，但它们也是不可变的，所以直接传递它们。|4486145|至于this或Go中调用的接收器的具体情况-同样的规则适用(请注意，与C%2B%2B不同，您可以使用内置类型作为接收器)，我认为编译器不够智能，无法避免复制，因此对大型结构使用指针。|4486146|entityMap^0|0|E|3|I|7|0|0|6|0|2|4|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|M|$]]

I would say your C++ knowledge will translate fine into Go about what is expensive as a function argument (passing structs by value) and what isn't (builtin types, eg int).

The major difference would be the reference types, slices, <code>map</code>s and <code>channel</code>s. These, though they appear to be passed by value (you don't need to use a pointer) are actually passed by reference, so don't in general use a pointer to a slice, map or channel.

<code>string</code>s are also special - they are reference types under the hood, but they are also immutable, so pass them around directly.

As for the specific case of <code>this</code> or the receiver as it is called in Go - same rules apply (note that you can have builtin types as a receiver unlike C++), and I don't think the compiler is smart enough to avoid copies, so use a pointer for large structs.

blocks|key|3018574|text|其他答案都很好，但在我看来，缺少一些信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3018575|Go中的接收器只是语法糖，如以下code所示|offset|length|3018576|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
}|code-block|syntax|javascript|3018577|在此基础上，考虑如果ChangeValue的接收方是Something类型的值而不是指向该类型的指针，会发生什么情况……|style|CODE|3018578|没错!你永远不可能通过这个方法来改变o的Value字段，大多数时候，你会使用指针接收器来进行封装。|3018579|entityMap|0|LINK|mutability|MUTABLE|url|http://play.golang.org/p/NtwQpZu580^0|0|G|4|0|0|0|A|B|Q|9|0|I|1|K|5|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@$D|15|E|16|M|N]|$D|17|E|18|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@$D|1A|E|1B|M|N]|$D|1C|E|1D|M|N]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

The other answers are good but in my opinion, there's some information missing.

Receivers in Go are just syntactic sugar, as demonstrated by the following <a href="http://play.golang.org/p/NtwQpZu580" rel="noreferrer">code</a>:

<pre><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
}
</code></pre>

Based on this, consider what would happen if the receiver of <code>ChangeValue</code> was a value of type <code>Something</code> instead of a pointer to one...

That's right! You could never actually mutate <code>o</code>'s <code>Value</code> field through this method. Most of the time, you use pointer receivers to do encapsulation.

blocks|key|952871|text|这取决于接收器的大小。如果接收器少于几十个字节，复制它实际上可能比传递指针所需的指针追逐(额外的内存访问)更便宜。此外，使用指针使结构更有可能被分配到堆上，这给垃圾收集器带来了额外的负担。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|952872|在Go中，拷贝总是一个字节一个字节的拷贝，因此成本只取决于结构的大小。在C%2B%2B中，它可能会调用复制构造函数，这可能会花费很多时间。|952873|因此，除了非常大的对象，根据方法的语义和与API的其余部分的一致性，只需使用任何类型的接收器就可以了。|952874|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It depends on the size of the receiver. If the receiver is less than a few dozen bytes, copying it might actually be cheaper than the pointer chasing (extra memory accesses) that would be required if you passed a pointer. Also, using a pointer makes it somewhat more likely that the struct will be allocated on the heap, putting an extra burden on the garbage collector.

In Go, the copy is always a byte-by-byte copy, so the cost depends only on the size of the struct. In C++ it might call a copy constructor, which could potentially take a lot of time.

So, except for really big objects, just use whatever kind of receiver makes the most sense based on the semantics of the method and consistency with the rest of your API.

I'm exploring Go after 9 years of C++ development. In C++ it is a bad practice to pass function's arguments by value except variables of built-in types because of performance penalty: all fields of the argument will be copied and in most cases it will be a very costly operation.

Is this true for Go? It looks very expensive to pass "this" by value only to assign "const" semantic to the method. Is Go compiler smart enough to prevent variable from being copied before first modification? Why isn't passing "this" by value an anti-pattern in Go as it is in C/C++?

Is there a performance penalty for passing "this" by value in Go methods?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在经历了9年的C++开发之后，我正在探索Go。在C++中，除了内置类型的变量外，按值传递函数的参数是一种不好的做法，因为会造成性能损失:参数的所有字段都将被复制，并且在大多数情况下，这将是一个非常昂贵的操作。Go也是这样吗？仅通过值传递"this“以将"const”语义赋值给方法看起来代价很高。Go编译器是否足够聪明，...

问在Go方法中通过值传递"this“是否会有性能损失？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Go方法中通过值传递"this“是否会有性能损失？EN