像 ForEach 一样使用 List<T>.RemoveAll 有什么缺点？

Question

在某些代码中，我使用 List<T>.RemoveAll 作为特殊的 List<T>.ForEach，它允许动态删除元素，因为我认为它会提供更好的性能：O(n) 与一个组合循环在 RemoveAll 与 O(2n) 中，一个 ForEach 和一个 RemoveAll。

例子：

gameObjects.RemoveAll( object => {
    if (object.Active){
        // Doing stuffs on object
    }
    return !object.Active;
});

至少在我的代码中，这个 hack 工作正常，因为它以正确的顺序迭代并且到目前为止没有遇到任何错误。

这种 hack 的一个缺点是代码的可维护性/可读性，因为它不是这种方法的原始目的，以后可能会引起混乱。

所以我的问题是：这种 hack 是否还有其他缺点（性能、可能的错误……）？

Answer 1

在一次迭代中做两倍的工作实际上并不比两次迭代的效率高一倍，每次都做一半的工作。

跑一圈一英里长的赛道，还是跑两圈半英里长的赛道，哪个更快？

尝试在一次迭代中完成所有这些操作会使代码变得不必要地复杂化，而且实际上并没有从中受益。只需调用RemoveAll 即可删除所有非活动项目，然后foreach 在集合上处理活动项目。

Answer 2

我并不是认为这是一种 hack，而是以特定方式使用设计元素。因为它似乎按照文档完成了它的工作删除所有与指定谓词定义的条件匹配的元素。 (List.RemoveAll )

...工作正常，因为它以正确的顺序迭代并且没有遇到 到目前为止的错误。

这里有两个步骤，一个是对每个项目进行操作，第二个是从列表中删除。使用此方法有效且可读。已经预先确定删除的确定这一事实是无关紧要的。

纯粹主义者会抱怨，但操作无论如何都需要循环遍历项目，为什么不集中工作。

代码可维护性/可读性

为了维护......只需将意图评论给任何未来的开发者。

这种 hack 是否还有其他缺点（性能、可能的错误……）？

不，当一个 逻辑上 可以完成时，我会将 hack 视为具有两个循环。

Answer 3

我在 Stackoverflow 上找到了这个： Stackoverflow - Maybe same 我想你的方法行得通，我认为没有问题，但正如你所说，有一天可能很难理解。我更喜欢“后循环”

这是上面 链接 中描述的另一种方式：正如智者所评论的那样，速度较慢 O(n*m) - 最坏的情况

var list = new List<int>(Enumerable.Range(1, 10));
for (int i = list.Count - 1; i >= 0; i--)
{
    if (list[i] > 5)
    list.RemoveAt(i);
 }
list.ForEach(i => Console.WriteLine(i));