當您想要使用不同語言的特定定界符拆分字符串時，這里有一些片段：# pythons = 'a,b,c,d,e'tokens = s.split(',')// javascriptlet s = 'a,b,c,d,e'let tokens = s.split(',')// gos := "a,b,c,d,e"tokens := strings.Split(s, ",")可以看到，split在Python和Javascript中是string類型的成員函數，在Go中不是。我想知道為什么，它看起來像 CPP 中的 STL，為什么操作類型實例的函數不是該類型的成員函數，在 Go 中實現它們似乎很容易，例如：// gofunc (s *string) Split(d string) []string { // here goes the code to split s with d given}這樣設計的原因是什么？
1 回答
慕神8447489
TA貢獻1780條經驗 獲得超1個贊
可以看到，split在python和javascript中是string類型的成員函數，在golang中不是。
這似乎從一開始就是如此：提交 729bc5c，2008 年 9 月，因為 Go1是第一個提到string Split()函數的提交。
基本的字符串實用程序。
這些函數被認為是“實用程序”，而不是預先聲明的字符串類型“?string”本身的一部分。
不久之后，它在2009 年 3 月的提交 0f7306b 中被記錄下來，仍然是 Go1
// Split returns the array representing the substrings of s separated by string sep. Adjacent
// occurrences of sep produce empty substrings.? If sep is empty, it is the same as Explode.
func Split(s, sep string) []string {
您可以在?2009 年 4 月的提交 5eae3b2中看到它首次使用func LookPath(file string) (string, *os.Error) {
字節與字節使用相同的方法：提交 7893322，2009 年 6 月；Go1，具有類似的 Split() 功能。
添加一個類似于字符串包的字節包。
總體思路是：您可以在不更改值類型本身的情況下更改該效用函數。
參見提交 30533d6，2009 年 6 月：
更改
strings.Split,bytes.Split以采用最大子字符串count參數。func?Split(s,?sep?[]byte,?n?int)?[][]byte
更劇烈的演變：提交 ebb1566，2011 年 6 月
strings.Split: 默認拆分所有。
假設完全拆分，將 Split 的簽名更改為沒有計數，并將Split具有計數的現有重命名為SplitN.
另一個想法是繼續使用string，同時可能在不需要時刪除對這些實用程序函數的依賴項（如2009 年 11 月提交的 35ace1d中：“刪除對strconv和的依賴項strings”）
它還允許添加更多相關功能，而無需觸及字符串本身。
請參閱提交 5d436b9，2009 年 11 月：lines :=?strings.SplitAfter(text, "\n", 0)，它使用Split().
另一個優勢：您可以獨立優化這些函數string，允許將重復的“拆分”函數替換為strings.Split().
參見提交 f388119，2013 年 3 月，Go 1.1
go/printer: 使用strings.Split而不是專用代碼使用更快的字符串包，專用代碼和 strings.Split 之間的區別在于噪音：
benchmark?????????old?ns/op????new?ns/op????delta BenchmarkPrint?????16724291?????16686729???-0.22%
相反的情況也是如此：用更簡單的代碼替換 strings.Split，如提交 d0c9b40，2015 年 9 月，Go 1.6
mime：刪除字解碼中的分配。
這通過用簡單的前綴/后綴檢查和一些自定義切片替換調用來修復
TODOin?。(*WordDecoder).Decodestrings.Split基準測試結果：
benchmark????????????????????old?ns/op?????new?ns/op?????delta BenchmarkQEncodeWord-8???????740???????????693???????????-6.35% BenchmarkQDecodeWord-8???????1291??????????727???????????-43.69% BenchmarkQDecodeHeader-8?????1194??????????767???????????-35.76%
（同樣的想法在提交 ecff943，2017 年 9 月，Go 1.11）
- 1 回答
- 0 關注
- 137 瀏覽
添加回答
舉報
0/150
提交
取消