LINQ：不属于任何VS都不 [英] LINQ: Not Any vs All Don't

问题描述

我经常要检查，如果提供的值列表中匹配一个（例如验证时）：

Often I want to check if a provided value matches one in a list (e.g. when validating):

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

最近，我发现ReSharper的问我，以简化这些查询到：

Recently, I've noticed ReSharper asking me to simplify these queries to:

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

显然，这在逻辑上是相同的，也许稍微更可读的（如果你已经做了很多数学），我的问题是：这是否导致性能的下降。

Obviously, this is logically identical, perhaps slightly more readable (if you've done a lot of mathematics), my question is: does this result in a performance hit?

感觉像它应该（即。任何（）听起来像它出现短路，而。所有（）听起来好像没有），但我没有什么可证明这一点。有没有人有较深的造诣，以查询是否将解决相同或ReSharper的是否误入歧途导致我？

It feels like it should (i.e. .Any() sounds like it short-circuits, whereas .All() sounds like it does not), but I have nothing to substantiate this. Does anyone have deeper knowledge as to whether the queries will resolve the same, or whether ReSharper is leading me astray?

推荐答案

实施所有根据ILSpy（如其实我去查了查，而不是好，该方法的工作原理有点像......我可能会做，如果我们讨论的理论，而不是影响）。

Implementation of All according to ILSpy (as in I actually went and looked, rather than the "well, that method works a bit like ..." I might do if we were discussing the theory rather than the impact).

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (!predicate(current))
        {
            return false;
        }
    }
    return true;
}

的

实施任何根据ILSpy：

Implementation of Any according to ILSpy:

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (predicate(current))
        {
            return true;
        }
    }
    return false;
}

当然，也有可能是在生产的IL一些细微的差别。但是，没有，没有没有。该IL是pretty的大致相同，但用于返回上predicate比赛真与假返回在predicate失配的明显反转。

Of course, there could be some subtle difference in the IL produced. But no, no there isn't. The IL is pretty much the same but for the obvious inversion of returning true on predicate match versus returning false on predicate mismatch.

这是LINQ换对象只能当然。这可能是一些其他的LINQ提供程序对待一个比另一个更好，但如果是这样的话，这是pretty的很多随机其中之一得到了更优化的实施。

This is linq-for-objects only of course. It's possible that some other linq provider treats one much better than the other, but then if that was the case, it's pretty much random which one got the more optimal implementation.

这似乎是规则归结只是为了一个人的感觉，如果（determineSomethingTrue）更简单，比更具可读性，如果（！determineSomethingFalse） 。而在公平，我认为他们已经有点点，我经常发现的如果（！someTest）混乱*时，有平等的冗长和复杂性的替代测试将返回true，因为我们希望在采取行动的条件。不过说真的，我个人觉得没有什么偏向了另一种你给的两个备选方案，而且或许会瘦略微朝向前如果predicate更复杂。

It would seem that the rule comes down solely to someone feeling that if(determineSomethingTrue) is simpler and more readable than if(!determineSomethingFalse). And in fairness, I think they've a bit of a point in that I often find if(!someTest) confusing* when there's an alternative test of equal verbosity and complexity that would return true for the condition we want to act upon. Yet really, I personally find nothing to favour one over the other of the two alternatives you give, and would perhaps lean very slightly toward the former if the predicate were more complicated.

*不混淆，因为在我不明白，而是混淆，因为在我担心，有一些微妙的原因，我不明白的决定，这需要一些精神跳过认识到，不，他们只是决定这样做的，等什么我望着code此位了吗？......

*Not confusing as in I don't understand, but confusing as in I worry that there's some subtle reason for the decision that I don't understand, and it takes a few mental skips to realise that "no, they just decided to do it that way, wait what was I looking at this bit of code for again?..."

这篇关于LINQ：不属于任何VS都不的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！