go语言为什么没有泛型 golang没有泛型( 三 )


*s = (*s)[:
len(*s)-1]
}
func (s *Stack) Push(value interface{}) {
*s =
append(*s, value)
}
但是,这里存在一个问题:每当你 Peek 项时,都必须使用类型断言将其从 interface{} 转换为你需要的类型 。如果你的堆栈是 *MyObject 的堆栈,则意味着很多 s.Peek().(*MyObject)这样的代码 。这不仅让人眼花缭乱,而且还可能引发错误 。比如忘记 * 怎么办?或者如果您输入错误的类型怎么办?s.Push(MyObject{})` 可以顺利编译,而且你可能不会发现到自己的错误,直到它影响到你的整个服务为止 。
通常,使用 interface{} 是相对危险的 。使用更多受限制的类型总是更安全 , 因为可以在编译时而不是运行时发现问题 。
泛型通过允许类型具有类型参数来解决此问题:
type Stack(type T) []Tfunc (s Stack(T)) Peek() T {
return s[len(s)-1]
}
func (s *Stack(T)) Pop() {
*s = (*s)[:
len(*s)-1]
}
func (s *Stack(T)) Push(value T) {
*s =
append(*s, value)
}
这会向 Stack 添加一个类型参数 , 从而完全不需要 interface{} 。现在,当你使用 Peek() 时,返回的值已经是原始类型,并且没有机会返回错误的值类型 。这种方式更安全,更容易使用 。(译注:就是看起来更丑陋,^-^)
此外,泛型代码通常更易于编译器优化,从而获得更好的性能(以二进制大小为代价) 。如果我们对上面的非泛型代码和泛型代码进行基准测试 , 我们可以看到区别:
type MyObject struct {
X
int
}
var sink MyObjectfunc BenchmarkGo1(b *testing.B) {
for i := 0; ib.N; i++ {
var s Stack
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink = s.Peek().(MyObject)
}
}
func BenchmarkGo2(b *testing.B) {
for i := 0; ib.N; i++ {
var s Stack(MyObject)
s.Push(MyObject{})
s.Push(MyObject{})
s.Pop()
sink = s.Peek()
}
}
结果:
BenchmarkGo1BenchmarkGo1-161283752887.0 ns/op48 B/op2 allocs/opBenchmarkGo2BenchmarkGo2-162840647941.9 ns/op24 B/op2 allocs/op
在这种情况下,我们分配更少的内存,同时泛型的速度是非泛型的两倍 。
合约(Contracts)
上面的堆栈示例适用于任何类型 。但是 , 在许多情况下,你需要编写仅适用于具有某些特征的类型的代码 。例如,你可能希望堆栈要求类型实现 String() 函数
驳狗屎文 "我为什么放弃Go语言此篇文章流传甚广, 其实里面没啥干货,而且里面很多观点是有问题的. 这个文章在 golang-china 很早就讨论过了.
最近因为 Rust 1.0 和 1.1 的发布, 导致这个文章又出来毒害读者.
所以写了这篇反驳文章, 指出其中的问题.
有好几次,当我想起来的时候,总是会问自己:我为什么要放弃Go语言?这个决定是正确的吗?是明智和理性的吗?其实我一直在认真思考这个问题 。
开门见山地说,我当初放弃Go语言(golang),就是因为两个“不爽”:第一 , 对Go语言本身不爽;第二,对Go语言社区里的某些人不爽 。毫无疑问,这是非常主观的结论 。但是我有足够详实的客观的论据,用以支撑这个看似主观的结论 。
文末附有本文更新日志 。
确实是非常主观的结论, 因为里面有不少有问题的观点(用来忽悠Go小白还行).
第0节:我的Go语言经历
先说说我的经历吧,以避免被无缘无故地当作Go语言的低级黑 。
2009年底,Go语言(golang)第一个公开版本发布 , 笼罩着“Google公司制造”的光环,吸引了许多慕名而来的尝鲜者,我(Liigo)也身居其中 , 笼统的看了一些Go语言的资料,学习了基础的教程 , 因对其语法中的分号和花括号不满 , 很快就遗忘掉了,没拿它当一回事 。

推荐阅读