views:

514

answers:

4

For the reasons that I still do not understand (see this SO question) multidimensional arrays in CLR do not implement IEnumerable<T>. So the following does not compile:

var m = new int[2,2] {{1, 2}, {3, 4}};
var q = from e in m select e;

Then how come that this works just fine in VB.NET?

Sub Main()
    Dim m(,) As Integer = {{1, 2}, {3, 4}}
    Dim q = From e In m Select e

    For Each i In q
        Console.WriteLine(i)
    Next
End Sub

Update:

The following code works because the C# compiler replaces the foreach with for loops to go through each dimension.

foreach(var e in m)
    Console.WriteLine(e);

becomes

int[,] numArray3 = new int[,] { { 2, 2 }, { 3, 3 } };
int upperBound = numArray3.GetUpperBound(0);
int num4 = numArray3.GetUpperBound(1);
for (int i = numArray3.GetLowerBound(0); i <= upperBound; i++)
{
    for (int j = numArray3.GetLowerBound(1); j <= num4; j++)
    {
        int num = numArray3[i, j];
        Console.WriteLine(num);
    }
}
+2  A: 

There are two reasons they don't implement it natively in C#:

  • There's more than one way you could do it. Do you want each 'cell', or do you want each 'row'? And how do you define 'row': [], IEnumerable, other? What if there are more than two dimensions? As soon as they pick one way, an army of developers will tell them they should have done it a different way.
  • Thanks to iterator blocks and the yield keyword, it just so easy to implement your own that's specific to your need at the time. Of course, that's a C# construct, but it's not that much harder in VB.
Joel Coehoorn
But as you can see from the question, VB.NET doesn't require it.
Prankster
@prankster: That's probably because of VB's roots. VB.Net carried over a lot of the hand holding programming aspects. This assumption of how you would want IEnumerable<T> implemented would be one of them.
Samuel
... added "in C#" to the end of the first sentence after prankster's comment.
Joel Coehoorn
+2  A: 

The MSDN page for Array includes this:

Important Note: In the .NET Framework version 2.0, the Array class implements the System.Collections.Generic.IList<T>, System.Collections.Generic.ICollection<T>, and System.Collections.Generic.IEnumerable<T> generic interfaces. The implementations are provided to arrays at run time,

Note the final words in the quote... it appears this generation does not happen for multi-dimensional arrays (so a documentation bug).

But as others have noted, what would T be? A good case can be made for T[] (or, these days with LINQ, IEnumerable<T>).

In the end, if you want to iterate all the array's members just stick with IEnumerable and Cast<T> extension. Otherwise easy to write your own.

Richard
+3  A: 

The query works in VB.Net because it gets transformed into

IEnumerable<object> q = m.Cast<object>().Select<object, object>(o => o);

This works because you can call Cast<TResult>() on IEnumerable, which [*,*] implements.

The LINQ query doesn't work in C# because of the different approach the C# and VB.Net designers took. VB.Net takes a more hand holding approach and fixes your mistake and converts IEnumerable to IEnumerable<object> so it can be used.

In C#, you can simulate this by using

var q = from e in m.Cast<object>() select e;
Samuel
Finally, man, I don't have all day to wait for your answer.
Prankster
+1  A: 

Tip: instead of Cast<object>() use a typed range variable


Samuel stated:

In C#, you can simulate this by using

var q = from e in m.Cast<object>() select e;
// q is of type IEnumerable<object>

which is of course correct as far as mimicking VB in C# is concerned, but you would loose your type information. Instead, it is much easier and as it turns out, slightly better readable, to simply declare your range variable.

The following compiles, performs better, is type safe and does not loose type information:

var m = new int[2, 2] { { 1, 2 }, { 3, 4 } };
var q = from int e in m select e;
// q is of type IEnumerable<int>

In the original suggestion, you would have an IEnumerable<object>, using int e you change that into IEnumerable<int>, which has its advantages.

Abel