too-many-lists/production-unsafe-deque/final-code

[giscus[bot]]

too-many-lists/production-unsafe-deque/final-code

https://course.rs/too-many-lists/production-unsafe-deque/final-code.html

[wzxzhuxi]

完结撒花！

[ChunyuPCY]

💪

[liegle]

疑惑 13.7.9 中

我发现 split_before 有四种潜在的情况：

• 正常情况
• 正常情况，但 prev 是幽灵节点
• 幽灵节点情况，我们返回整个列表，然后变成空列表
• 幽灵节点情况，但列表是空的，所以什么也不做，返回空列表

好像第二种情况并没有正确处理？目前的代码 prev 是幽灵节点时，依然会会 let output_front = self.list.front，导致返回的列表 front 是 self.list.front，而 back 是 None。split_after 也有类似的情况

作者说

你可能注意到，我们没有处理 prev 是幽灵节点的情况。但据我所知，其他一切都只是顺便做了正确的事。等我们写测试的时候就知道了！

但是测试里似乎也没测到这种情况

[pejaz]

我也想到了这个问题。后面我猜测是和链表布局有关，想象这个链表是通过幽灵节点变成一个环。
[ghost] -> A(list.front ) <-> B <-> C <-> D(list.back) <- [ghost]，
所以 peek_next时 假设cur 指向链表前面的幽灵节点，其实也是同时指向后面的幽灵节点，此时就只考虑self.list.back是否有值，有就返回self.list.back。
这个也可以解释 split_before时 prev 是幽灵节点下 返回列表的 front 是 self.list.front 的情况。但是此时 back 为什么是 None我也想不明白，希望其他人可以补充解释下为什么🙁