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

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

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

123

4567

891011

1213

1415

1617

1819

2021

2223

2425

2627

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

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

123

456

before removing... removing 1 after removing...23

4

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

下面是remove方法的**：

123

4567

8910

// 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了，**如下：

123

4567

891011

1213

1415

1617

1819

2021

2223

2425

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

正常結果輸出：

123

456

before removing... removing 1 removing 2 removing 3 removing 4 after removing...

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

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

mongodb的乙個小坑

Mybatis的乙個小坑

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

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

mongodb的乙個小坑

Mybatis的乙個小坑

相關推薦