Go的List操作上的乙個小「坑」

一直想不清楚乙個問題，簡單設計的東西到底是「坑多」還是「坑少」呢？複雜的設計，考慮的太全面，使用起來更麻煩，使用者容易陷入亂，落入自身的陷阱;而簡單的設計呢，在許多方面上又顧及不周，如果使用者對其「設計」沒仔細研究，或者其實現本身又是乙個黑盒子，也容易掉入到設計本身遺留下來的「陷阱」。下面是我剛開始使用go寫**時碰到的乙個小「坑」，這個「坑」的原因我歸結為後者。

這個「小坑」來自於go的container/list package的使用上。導致「坑」的**大概如下所示：

package main
import ( "
container/list""
fmt"
)func main() 
fmt.println(
"after removing...")
//遍歷刪除完元素後的list
for e := l.front(); e != nil; e =e.next() 
}

以上**很簡單，按常理來看，應該能得到正確的結果，list最後將會被清空。可事實卻完全不是這樣，執行後結果如下：

before removing...

removing

1after removing...23

從結果可以看出，list根本沒有清空，而只是刪除了第乙個元素。這是為何？原因就在container/list package的實現上了。這應該是我見過的實現最簡單list了，出去注釋也就100來行實現**，而且它不只是乙個簡單鍊錶，而且可以當做stack，當做queue來使用。

下面是remove方法的**：

//
remove removes e from its list, decrements l.len, and returns e.
func (l *list) remove(e *element) *element

這下問題原因就明顯了，就出現在e.next = nil 這行**上。當執行玩remove,e.next就變成了nil,list遍歷當然也就終止了。找出問題的原因，我們就容易找到workaround的辦法了，將e.next用中間變數儲存起來就ok了，**如下：

package main
import (
"container/list""
fmt"
)func main() 
fmt.println(
"after removing...")
for e := l.front(); e != nil; e =e.next() 
}

正常結果輸出：

before removing...

removing

1removing

2removing

3removing

4after removing...

Go的List操作上的乙個小「坑」

Go的List操作上的乙個小「坑」

mongodb的乙個小坑

Mybatis的乙個小坑

Go的List操作上的乙個小「坑」

Go的List操作上的乙個小「坑」

mongodb的乙個小坑

Mybatis的乙個小坑

相關推薦