Find items from a list which exist in another list

Question

I have a List<PropA>

PropA  
{  
    int a;  
    int b;  
}

and another List<PropX>

PropX  
{  
    int a;  
    int b;  
}

Now i have to find items from List<PropX> which exist in List<PropA> matching b property using lambda or LINQ.

Solution 1

What you want to do is Join the two sequences. LINQ has a Join operator that does exactly that:

List<PropX> first;
List<PropA> second;

var query = from firstItem in first
    join secondItem in second
    on firstItem.b equals secondItem.b
    select firstItem;

Note that the Join operator in LINQ is also written to perform this operation quite a bit more efficiently than the naive implementations that would do a linear search through the second collection for each item.

Solution 2

ListA.Where(a => ListX.Any(x => x.b == a.b))

Solution 3

var commonNumbers = first.Intersect(second); 

This will give you the common values between two lists, a much faster and cleaner approach than join or other Lambda expressions.

Just try it.

Source : MSDN

Solution 4

Well all above will not work if you have multiple parameters, So I think this is the best way to do it.

For example: Find not matched items from pets and pets2 .

var notMatchedpets = pets
    .Where(p2 => !pets2
    .Any(p1 => p1.Name == p2.Name && p1.age == p2.age))
    .ToList();

View more solutions

Comments

[walther]

And what have you tried so far? This question has been answered way too many times already...

[Dave Bish]

code.msdn.microsoft.com/LINQ-Set-Operators-374f34fe

[Servy]

@David Perhaps they each have different fields that he hasn't shown, or they have a different set of methods even though they have the same values, or any number of other reasons.

[David]

got it! I thought both a & b should match. It is my mistake.

[Malcolm O'Hare]

There is also the other way of writing this... first.Join(second, f => f.b, s => s.b, (fir, sec) => fir);

[Servy]

@MalcolmO'Hare Yes, and both are completely identical. This will compile into that. I've found that most people prefer Join to be written out using query syntax over method syntax, even more so than any of the other query methods.

[Servy]

Well, I ran a simple test and the results of a Join were substantially faster. ideone.com/xW1CnL . You'll need to run the code yourself to use a larger data set.

[Adrian Godong]

Yep, I forgot to run the query. It seems that for a small enough data set (less than 500 items), the instantiation cost of join outweighs the performance gain.

[Adrian Godong]

If performance is out of the question, then I would take code simplicity. This would be a subjective and personal preference.

[Adrian Godong]

Depending on how the business logic and input data goes, one may want to include a Distinct() call to remove duplicate values returned by the join.

[Servy]

And in this case the operation being performed is fundamentally a join. That is the semantic meaning of this code, so it makes the most sense to use that exact operator rather than using Where to implement your own Join. Join does a better job of conveying the meaning to the reader as a result.

[Daniel]

This would only work if T was the same type for both IEnumerable<T> collections, which is not the case in the question asked.

[Simo Kivistö]

+1, This is one of those cases where you open the question based on the title and this is the perfect answer to that part although it doesn't answer the actual content of the question.

[Ambuj]

Thanks Simo Kivisto