struct的方法,如果receiver非指標,則呼叫這個方法無法改變物件狀態,因為傳遞給方法的物件是原物件的乙個拷貝,所有的改變都被作用在這個拷貝上而非原物件上.
type st struct
func (this st) show()
func (this st) increase()
func main()
b.increase()
b.show()
}
輸出:
increase:11
show:10
對於習慣了c++的程式設計師,總會認為呼叫乙個物件的非const方法是可以改變那個物件的內部狀態.但是這種思維如果延續到go中將會導致很難查詢的bug.
到底是物件實現了介面還是指向物件的指標實現了介面
先來看以下**:
package main
import "fmt"
type intf inte***ce
type st struct
func (this *st) show()
func main()
a = b
a.show()
}
直觀上我們認為st實現了intf介面,所以可以用b對a賦值,而實際上執行這段**將會報錯:
# command-line-arguments
test/test.go:21: cannot use b (type st) as type intf in assignment:
st does not implement intf (show method has pointer receiver)
這段提示說st沒有實現intf介面,因為show方法的receiver是乙個指標.對**稍作修改:
func main()
a = b
a.show()
}
這次**可以正確執行了,此時b應該是乙個指向st的指標.這是說*st實現了intf介面?
現在我再把show的定義改一下,main不變:
func (this st) show()
**還是可以正確執行,同時如果把main恢復成下面這樣:
func main()
a = b
a.show()
}
**也是正確的.
也就是說,實現介面的方法時receiver是指標那麼只能用實現型別的指針對介面賦值,否則既能用實現型別的值也能用實現型別的指針對介面賦值.
最後再來看個例子,在一段網路**中,我想將net.conn轉換成net.tcpconn,如下**報錯:
tcpconn := this.conn.(net.tcpconn)
# kendynet-go/socket
./tcpsession.go:156: impossible type assertion:
net.tcpconn does not implement net.conn (close method has pointer receiver)
makefile:2: recipe for target 'all' failed
正確的做法是:
tcpconn := this.conn.(*net.tcpconn)
這是否證明了,是*net.tcpconn而不是net.tcpconn實現了net.conn介面, 一些吐槽 1
今天我吐槽一下頻繁使用的兩個軟體,屬於是不吐 不快的那種。這是乙個 系統軟體。有快半年了罷,我對它體驗的感受就是 win10 lite。稱為lite乙個原因是ui更幼了。雖然大家都說是像蘋果致敬。另外乙個就是把太多東西化簡為繁了,感覺起來卻像是閹割了不少功能。這個是 窗戶 11 的資料夾介面。雀食是...
演算法課設(巨水)和一些吐槽
首先我要吐槽一下,大二下學期的課程才有演算法,而且學的都是人家初中生玩剩下的普及組的題,這個課程安排真的是有毛病。先學資料結構和演算法,把硬體 數字邏輯 計算機組成原理 和經濟學原理 管理學這些沒什麼用的課程砍掉不香嗎?講道理,大學的計科專業真的是什麼都學,什麼都不精,包括一些 我認為 沒什麼用的課...
go語言的一些經驗理解
注 go build是將原始碼檔案編譯成乙個二進位制的可執行檔案,如go build test.go可以在test.go所在的imooc檔案目錄下生成乙個test可執行檔案。只需.test便可輸出執行結果。go run則是將程式直接執行並輸出結果,不會生成二進位制可執行檔案。2 我們要保證我們執行編...