指针与参数和返回值中的值

小编典典

指针与参数和返回值中的值

在Go中，有多种方法可以返回struct值或其片段。对于个人，我已经看到：

type MyStruct struct {
    Val int
}

func myfunc() MyStruct {
    return MyStruct{Val: 1}
}

func myfunc() *MyStruct {
    return &MyStruct{}
}

func myfunc(s *MyStruct) {
    s.Val = 1
}

我了解两者之间的区别。第一个返回该结构的副本，第二个返回指向在函数内创建的结构值的指针，第三个期望传入现有结构并覆盖该值。

我已经看到所有这些模式都可以在各种情况下使用，我想知道关于这些的最佳实践是什么。什么时候使用？例如，第一个可能适用于小型结构（因为开销很小），第二个适用于较大的结构。第三，如果您想提高存储效率，因为您可以轻松地在调用之间重用单个结构实例。有什么最佳实践，何时使用？

同样，关于切片的相同问题：

func myfunc() []MyStruct {
    return []MyStruct{ MyStruct{Val: 1} }
}

func myfunc() []*MyStruct {
    return []MyStruct{ &MyStruct{Val: 1} }
}

func myfunc(s *[]MyStruct) {
    *s = []MyStruct{ MyStruct{Val: 1} }
}

func myfunc(s *[]*MyStruct) {
    *s = []MyStruct{ &MyStruct{Val: 1} }
}

再说一遍：什么是最佳实践。我知道切片始终是指针，因此返回指向切片的指针没有用。但是，我应该返回一个结构值切片，一个指向结构的指针切片，是否应该将指向切片的指针作为参数传递（Go
App Engine
API中使用的模式）？

阅读 290

2020-07-02

共1个答案

小编典典

tl; dr ：

使用接收器指针的方法很常见。接收者的经验法则是：“如有疑问，请使用指针”。
切片，映射，通道，字符串，函数值和接口值是在内部使用指针来实现的，指向它们的指针通常是多余的。
在其他地方，将指针用于大型结构或您必须更改的结构，否则传递值，因为通过指针使事情意外更改会造成混淆。

一种应该经常使用指针的情况：

接收器 比其他参数更经常地使用指针。方法修改被调用的东西或命名类型为大型结构并不罕见，因此，在极少数情况下，指南是默认使用指针。
- 杰夫·霍奇斯（Jeff Hodges）的copyfighter工具自动搜索按值传递的非微小接收者。

在一些不需要指针的情况下：

代码审查指南建议将 小结构（ 如type Point struct { latitude, longitude float64 }，甚至可能更大的东西）作为值传递，除非您调用的函数需要能够就地对其进行修改。
- 值语义避免混叠情况，在此情况下，此处的赋值会意外更改其值。
- 牺牲一些干净的语义来加快速度并不是一件容易的事，有时通过值传递小结构实际上会更有效，因为它避免了高速缓存未命中或堆分配。
- 因此，Go Wiki的代码审查注释页建议在结构较小且可能会保持这种状态时按值传递。
- 如果“大”临界值似乎含糊，那就是；可以说，许多结构都在指针或值确定的范围内。作为下限，代码审查注释建议切片（三个机器字）可以合理地用作值接收者。接近上限时，bytes.Replace需要使用10个单词的args（三个切片和一个int）。
对于 slices ，您不需要传递指针来更改数组的元素。例如，io.Reader.Read(p []byte)更改的字节p。可以说这是“对待像值一样的小结构”的特例，因为在内部，您正在传递一个称为 切片头 的小结构（请参阅Russ Cox（rsc）的说明）。同样，您也不需要指针来 修改地图或在channel上进行通信 。
对于 切片，您将 进行切片（更改其开始/长度/容量），内置函数，例如append接受切片值并返回一个新值。我会模仿的；它避免了混淆，返回一个新的分片有助于引起人们注意可能分配了一个新数组的事实，并且调用者很熟悉它。
- 遵循这种模式并不总是可行的。一些工具，例如数据库接口或序列化器，需要追加到在编译时类型未知的片上。他们有时会接受指向interface{}参数中切片的指针。
- 映射，通道，字符串以及函数和接口值 （例如切片）是内部引用或已经包含引用的结构，因此，如果您只是试图避免复制基础数据，则无需将指针传递给它们。（rsc 撰写了有关如何存储接口值的单独文章）。
- 您可能仍然需要通过指针在罕见的情况下，要修改调用者的结构：flag.StringVar需要一个*string出于这个原因，例如。

使用指针的位置：

考虑您的函数是否应该是您需要指向的任何结构上的方法。人们期望有很多方法可以x进行修改x，因此使接收器成为修改后的结构可能有助于最大程度地减少意外。对于何时应该将接收者作为指针有一些指导。
对非接收器参数有影响的函数应该在godoc中，或者更好的是，在godoc和名称（如reader.WriteTo(writer)）中明确指出。
您提到接受一个指针，以允许通过重用避免分配。为了内存重用而更改API是一种优化，我会延迟直到明显知道分配费用不菲，然后再寻找一种不会对所有用户强制使用棘手API的方法：
1. 为了避免分配，Go的转义分析是您的朋友。您有时可以通过创建可以用平凡的构造函数，纯文本或有用的零值初始化的类型来帮助避免堆分配bytes.Buffer。
2. 考虑一些Reset()将对象放回空白状态的方法，例如某些stdlib类型提供的方法。不在乎或无法保存分配的用户不必调用它。
3. 为方便起见，existingUser.LoadFromJSON(json []byte) error可以考虑编写就地修改方法和从头创建函数作为匹配对，以方便使用：可以用进行包装NewUserFromJSON(json []byte) (*User, error)。再次，它在懒惰和捏分配给单个呼叫者之间做出选择。
4. 寻求回收内存的调用者可以让他们sync.Pool处理一些细节。如果特定的分配产生了很大的内存压力，您有信心知道何时不再使用该分配，并且没有更好的优化方法可以提供sync.Pool帮助。（CloudFlare发表了sync.Pool关于回收的有用（上）博客文章。）

最后，关于切片是否应该是指针：值切片可以很有用，并且可以节省分配和缓存未命中。可能有阻止者：

用于创建商品的API 可能会强制您使用指针，例如，您必须调用NewFoo() *Foo而不是让Go初始化为零值。
这些项目的期望寿命 可能不尽相同。整个切片立即被释放；如果99％的项目不再有用，但您有指向其他1％的指针，则所有数组均保持分配状态。
到处移动项目 可能会引起问题。值得注意的是，append在增长基础数组时会复制项目。指向append错误位置之后的指针，对于大型结构，复制可能会变慢，并且例如，sync.Mutex不允许复制。在中间插入/删除并类似地移动项目。

从广义上讲，如果您将所有物品放在前面就位并且不移动它们（例如，append在初始设置后不再移动），或者如果您确实一直在移动它们，但是您确定可以（无需/小心使用指向项目的指针，项目足够小以至于无法有效复制等）。有时您必须考虑或衡量具体情况，但这只是一个粗略的指导。

2020-07-02