一直想不清楚一个问题,简单设计的东西到底是“坑多”还是“坑少”呢? 复杂的设计,考虑的太全面,使用起来更麻烦,使用者容易陷入乱,落入自身的陷阱;而简单的设计呢,在许多方面上又顾及不周,如果使用者对其“设计”没仔细研究,或者其实现本身又是一个黑盒子,也容易掉入到设计本身遗留下来的“陷阱”。下面是我刚开始使用Go写代码时碰到的一个小“坑”,这个“坑”的原因我归结为后者。
这个“小坑”来自于go的container/list package的使用上。导致“坑”的代码大概如下所示:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
package main
import (
"container/list"
"fmt"
)
func main() {
//初始化一个list
l := list.New()
l.PushBack(1)
l.PushBack(2)
l.PushBack(3)
l.PushBack(4)
fmt.Println("Before Removing...")
//遍历list,删除元素
for e := l.Front(); e != nil; e = e.Next() {
fmt.Println("removing", e.Value)
l.Remove(e)
}
fmt.Println("After Removing...")
//遍历删除完元素后的list
for e := l.Front(); e != nil; e = e.Next() {
fmt.Println(e.Value)
}
}
|
以上代码很简单,按常理来看,应该能得到正确的结果,list最后将会被清空。可事实却完全不是这样,执行后结果如下:
1
2
3
4
5
6
|
Before Removing...
removing 1
After Removing...
2
3
4
|
从结果可以看出,list根本没有清空,而只是删除了第一个元素。这是为何?原因就在container/list package的实现上了。这应该是我见过的实现最简单list了,出去注释也就100来行实现代码,而且它不只是一个简单链表,而且可以当做stack,当做queue来使用。
下面是Remove方法的代码:
1
2
3
4
5
6
7
8
9
10
|
// remove removes e from its list, decrements l.len, and returns e.
func (l *List) remove(e *Element) *Element {
e.prev.next = e.next
e.next.prev = e.prev
e.next = nil // avoid memory leaks
e.prev = nil // avoid memory leaks
e.list = nil
l.len--
return e
}
|
这下问题原因就明显了,就出现在e.next = nil 这行代码上。当执行玩remove,e.next就变成了nil,list遍历当然也就终止了。找出问题的原因,我们就容易找到workaround的办法了,将e.next用中间变量保存起来就OK了,代码如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
package main
import (
"container/list"
"fmt"
)
func main() {
l := list.New()
l.PushBack(1)
l.PushBack(2)
l.PushBack(3)
l.PushBack(4)
fmt.Println("Before Removing...")
var n *list.Element
for e := l.Front(); e != nil; e = n {
fmt.Println("removing", e.Value)
n = e.Next()
l.Remove(e)
}
fmt.Println("After Removing...")
for e := l.Front(); e != nil; e = e.Next() {
fmt.Println(e.Value)
}
}
|
正常结果输出:
1
2
3
4
5
6
|
Before Removing...
removing 1
removing 2
removing 3
removing 4
After Removing...
|