2 Lists
-
Great! Thx.
-
You can do the following:
var lst1 = new List<int>() { 1, 2, 3, 4, 5, 6 };
var lst2 = new List<int>() { 1, 3, 2, 7, 5, 9 };var items = lst1.Where((item, index) => (item == lst2[index]));
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
The power of LINQ never ceases to amaze me. I never thought of that possible solution.
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog
-
The power of LINQ never ceases to amaze me. I never thought of that possible solution.
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog
OT what other solutions had you thought of? I was scratching my head a few weeks ago about indexing things in LINQ and by chance happened to scroll through the tooltips and noticed that extension method which was the ideal situation. It is amazing what you can do with LINQ, I know it can produce "bloated" code afterwards but do we really care, as long as it makes our life easier. Otherwise we'd still be programming in assembly. I'll always remember showing a fellow student what 2 lines of LINQ (could have been one) could do, compared to what we'd had to write in Delphi for our labs. :-\
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
-
You can do the following:
var lst1 = new List<int>() { 1, 2, 3, 4, 5, 6 };
var lst2 = new List<int>() { 1, 3, 2, 7, 5, 9 };var items = lst1.Where((item, index) => (item == lst2[index]));
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
Thanks, I've been wondering what the heck that 2nd int param in where was for :P Kind of obvious now :doh:
-
Thanks, I've been wondering what the heck that 2nd int param in where was for :P Kind of obvious now :doh:
-
OT what other solutions had you thought of? I was scratching my head a few weeks ago about indexing things in LINQ and by chance happened to scroll through the tooltips and noticed that extension method which was the ideal situation. It is amazing what you can do with LINQ, I know it can produce "bloated" code afterwards but do we really care, as long as it makes our life easier. Otherwise we'd still be programming in assembly. I'll always remember showing a fellow student what 2 lines of LINQ (could have been one) could do, compared to what we'd had to write in Delphi for our labs. :-\
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
Well, indexing works only when at least one of the types is an IList. I would have used a helper function like this: IEnumerable> Zip(IEnumerable input1, IEnumerable input2) { using (IEnumerator e1 = input1.GetEnumerator()) using (IEnumerator e2 = input2.GetEnumerator()) { while (e1.MoveNext() && e2.MoveNext()) yield return new Pair(e1.Current, e2.Current); } } And then "from pair in Zip(list1, list2) where pair.First == pair.Second select pair.First"
-
Well, indexing works only when at least one of the types is an IList. I would have used a helper function like this: IEnumerable> Zip(IEnumerable input1, IEnumerable input2) { using (IEnumerator e1 = input1.GetEnumerator()) using (IEnumerator e2 = input2.GetEnumerator()) { while (e1.MoveNext() && e2.MoveNext()) yield return new Pair(e1.Current, e2.Current); } } And then "from pair in Zip(list1, list2) where pair.First == pair.Second select pair.First"
Looking through the relevant methods in Reflector I don't think that's the case because the enumerator keeps a local index going of where it is so it'll work for any
IEnumerable<T>interace.
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
-
Looking through the relevant methods in Reflector I don't think that's the case because the enumerator keeps a local index going of where it is so it'll work for any
IEnumerable<T>interace.
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
Sure, you always get the index during enumeration, but you cannot do anything with it; list2[index] won't compile if list2 is just an IEnumerable. You would have to go through the second enumerable multiple times (very bad performance) or use .ToList() to get a temporary list (could use a lot of memory unnecessarily).
-
Sure, you always get the index during enumeration, but you cannot do anything with it; list2[index] won't compile if list2 is just an IEnumerable. You would have to go through the second enumerable multiple times (very bad performance) or use .ToList() to get a temporary list (could use a lot of memory unnecessarily).
The point is that for the situation outlined in the OP the index is generated dynamically while iterating over the list to do the filtering so you can't really get much more efficient. You've already created an enumerator for the list and that just has an
intwhich counts how many timesMoveNext()was called.
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
-
The point is that for the situation outlined in the OP the index is generated dynamically while iterating over the list to do the filtering so you can't really get much more efficient. You've already created an enumerator for the list and that just has an
intwhich counts how many timesMoveNext()was called.
I doubt it. If it isn't intuitive then we need to fix it. - Chris Maunder
Your solution is perfectly fine for the context where the OP is using it. Mine is more general (doesn't require IList, just IEnumerable), doesn't crash when the lists have different lengths (whether this is good depends of course highly depends on what you want to do). And in your solution, inserting new items in list1 while the query is evaluated will result in an InvalidOperationException (collection modified during enumeration), but inserting new items in list2 doesn't. The Zip solution is symmetric regarding input1/input2 (throws InvalidOperationException in both cases).