The String.Split method breaks a string into multiple strings based on separator characters. You tell it which characters to treat as separators by passing a char array. Example 7-8 splits on spaces, commas, and periods.

string[] items = inputString.Split(
    new char[] { ' ', ',', '.' },
    StringSplitOptions.RemoveEmptyEntries);

If inputString contained "One,Two Three, Four. Five.", this would put a five-element array into items containing the strings "One", "Two", "Three", "Four", and "Five".

Example 7-8 asks Split to ignore empty items so that when we get both a period and a space in succession we don’t get an empty string in the results to represent the fact that there were two separators. If you don’t need to skip such things, there’s a simpler overload of Split that illustrates yet another way to initialize an array:

string[] items = inputString.Split(' ', ',', '.'),

It looks like we’ve passed three char arguments to this method. But there’s no such overload of Split—this ends up calling an overload that looks like this:

public string[] Split(params char[] separator) ...

That params keyword is significant. When an argument is marked with this keyword, C# lets you use syntax that makes it look like a series of individual arguments, and it will create an array from these for you. (You’re free to provide the array explicitly if you prefer.) The params keyword can be used on only the very last argument of a method, to avoid potential ambiguity about which values go into arrays and which become arguments in their own right. That’s why Example 7-8 had to create the array explicitly.

The examples so far contain nothing but strings. This is a poor way to represent events in a calendar—it would be useful to know when each event occurs. We could add a second array of type DateTimeOffset[] whose elements correspond to the event names in the original array. But spreading related data across multiple arrays can make code awkward to write and hard to maintain. Fortunately, there’s a better way.

Suppose we want to find out if an array of calendar items contains any events that start on a particular date. An obvious way to do this would be to write a loop that iterates through all of the elements in the array, looking at each date in turn (see Example 7-13).

DateTime dateOfInterest = new DateTime (2009, 7, 12);
foreach (CalendarEvent item in events)
{
    if (item.StartTime.Date == dateOfInterest)
    {
        Console.WriteLine(item.Title + ": " + item.StartTime);
    }
}

Although Example 7-13 works just fine, the Array class provides an alternative: its FindAll method builds a new array containing only those elements in the original array that match whatever criteria you specify. Example 7-14 uses this method to do the same job as Example 7-13.

DateTime dateOfInterest = new DateTime (2009, 7, 12);
CalendarEvent[] itemsOnDateOfInterest = Array.FindAll(events,
    e => e.StartTime.Date == dateOfInterest);

foreach (CalendarEvent item in itemsOnDateOfInterest)
{
    Console.WriteLine(item.Title + ": " + item.StartTime);
}

Notice that we’re using a lambda expression to tell FindAll which items match. That’s not mandatory—FindAll requires a delegate here, so you can use any of the alternatives discussed in Chapter 5, including lambda expressions, anonymous methods, method names, or any expression that returns a suitable delegate. The delegate type here is Predicate<T>, where T is the array element type (Predicate<CalendarEvent> in this case). We also discussed predicate delegates in Chapter 5, but in case your memory needs refreshing, we just need to supply a function that takes a CalendarEvent and returns true if it matches, and false if it does not. Example 7-14 uses the same expression as the if statement in Example 7-13.

This may not seem like an improvement on Example 7-13. We’ve not written any less code, and we’ve ended up using a somewhat more advanced language feature—lambda expressions—to get the job done. However, notice that in Example 7-14, we’ve already done all the work of finding the items of interest before we get to the loop. Whereas the loop in Example 7-13 is a mixture of code that works out what items we need and code that does something with those items, Example 7-14 keeps those tasks neatly separated. And if we were doing more complex work with the matching items, that separation could become a bigger advantage—code tends to be easier to understand and maintain when it’s not trying to do too many things at once.

The FindAll method becomes even more useful if you want to pass the set of matching items on to some other piece of code, because you can just pass the array of matches it returns as an argument to some method in your code. But how would you do that with the approach in Example 7-13, where the match-finding code is intermingled with the processing code? While the simple foreach loop in Example 7-13 is fine for trivial examples, FindAll and similar techniques (such as LINQ, which we’ll get to in the next chapter) are better at managing the more complicated scenarios likely to arise in real code.

The Array class offers a few variations on the FindAll theme. If you happen to be interested only in finding the first matching item, you can just call Find. Conversely, FindLast returns the very last matching item.

Sometimes it can be useful to know where in the array a matching item was found. So as an alternative to Find and FindLast, Array also offers FindIndex and FindLastIndex, which work in the same way except they return a number indicating the position of the first or last match, rather than returning the matching item itself.

Finally, one special case for finding the index of an item turns out to crop up fairly often: the case where you know exactly which object you’re interested in, and just need to know where it is in the array. You could do this with a suitable predicate, for example:

int index = Array.FindIndex(events, e => e == someParticularEvent);

But Array offers the more specialized IndexOf and LastIndexOf, so you only have to write this:

int index = Array.IndexOf(events, someParticularEvent);

Sometimes it’s useful to modify the order in which entries appear in an array. For example, with a calendar, some events will be planned long in advance while others may be last-minute additions. Any calendar application will need to be able to ensure that events are displayed in chronological order, regardless of how they were added, so we need some way of getting items into the right order.

The Array class makes this easy with its Sort method. We just need to tell it how we want the events ordered—it can’t really guess, because it doesn’t have any way of knowing whether we consider our events to be ordered by the Title, StartTime, or Duration property. This is a perfect job for a delegate: we can provide a tiny bit of code that looks at two CalendarEvent objects and says whether one should appear before the other, and pass that code into the Sort method (see Example 7-15).

Array.Sort(events,
    (event1, event2) => event1.StartTime.CompareTo(event2.StartTime));

The Sort method’s first argument, events, is just the array we’d like to reorder. (We defined that back in Example 7-10.) The second argument is a delegate, and for convenience we again used the lambda syntax introduced in Chapter 5. The Sort method wants to be able to know, for any two events, whether one should appear before the other, It requires a delegate of type Comparison<T>, a function which takes two arguments—we called them event1 and event2 here—and which returns a number. If event1 is before event2, the number must be negative, and if it’s after, the number must be positive. We return zero to indicate that the two are equal. Example 7-15 just defers to the StartTime property—that’s a DateTimeOffset, which provides a handy CompareTo method that does exactly what we need.

It turns out that Example 7-15 isn’t changing anything here, because the events array created in Example 7-10 happens to be in ascending order of date and time already. So just to illustrate that we can sort on any criteria, let’s order them by duration instead:

Array.Sort(events,
    (event1, event2) => event1.Duration.CompareTo(event2.Duration));

This illustrates how the use of delegates enables us to plug in any number of different ordering criteria, leaving the Array class to get on with the tedious job of shuffling the array contents around to match the specified order.

Some data types such as dates or numbers have an intrinsic ordering. It would be irritating to have to tell Array.Sort how to work out whether one number comes before or after another. And in fact we don’t have to—we can pass an array of numbers to a simpler overload of the Sort method, as shown in Example 7-16.

int[] numbers = { 4, 1, 2, 5, 3 };
Array.Sort(numbers);

As you would expect, this arranges the numbers into ascending order. We would provide a comparison delegate here only if we wanted to sort the numbers into some other order. You might be wondering what would happen if we tried this simpler method with an array of CalendarEvent objects:

Array.Sort(events);  // Blam!

If you try this, you’ll find that the method throws an InvalidOperationException, because Array.Sort has no way of working out what order we need. It works only for types that have an intrinsic order. And should we want to, we could make CalendarEvent self-ordering. We just have to implement an interface called IComparable<CalendarEvent>, which provides a single method, CompareTo. Example 7-17 implements this, and defers to the DateTimeOffset value in StartTime—the DateTimeOffset type implements IComparable<DateTimeOffset>. So all we’re really doing here is passing the responsibility on to the property we want to use for ordering, just like we did in Example 7-15. The one extra bit of work we do is to check for comparison with null—the IComparable<T> interface documentation states that a non-null object should always compare as greater than null, so we return a positive number in that case. Without this check, our code would crash with a NullReferenceException if null were passed to CompareTo.

class CalendarEvent : IComparable<CalendarEvent>
{
    public string Title { get; set; }
    public DateTimeOffset StartTime { get; set; }
    public TimeSpan Duration { get; set; }


    public int CompareTo(CalendarEvent other)
    {
        if (other == null) { return 1; }
        return StartTime.CompareTo(other.StartTime);
    }
}

Now that our CalendarEvent class has declared an intrinsic ordering for itself, we are free to use the simplest Sort overload:

Array.Sort(events);  // Works, now that CalendarEvent is IComparable<T>

Getting your array contents in order isn’t the only reason for relocating elements, so Array offers some slightly less specialized methods for moving data around.

Suppose you want to build a calendar application that works with multiple sources of information—maybe you use several different websites with calendar features and would like to aggregate all the events into a single list. Example 7-18 shows a method that takes two arrays of CalendarEvent objects, and returns one array containing all the elements from both.

static CalendarEvent[] CombineEvents(CalendarEvent[] events1,
                                     CalendarEvent[] events2)
{
    CalendarEvent[] combinedEvents =
        new CalendarEvent[events1.Length + events2.Length];
    events1.CopyTo(combinedEvents, 0);
    events2.CopyTo(combinedEvents, events1.Length);

    return combinedEvents;
}

This example uses the CopyTo method, which makes a complete copy of all the elements of the source array into the target passed as the first argument. The second argument says where to start copying elements into the target—Example 7-18 puts the first array’s elements at the start (offset zero), and then copies the second array’s elements directly after that. (So the ordering won’t be very useful—you’d probably want to sort the results after doing this.)

You might sometimes want to be a bit more selective—you might want to copy only certain elements from the source into the target. For example, suppose you want to remove the first event. Arrays cannot be resized in .NET, but you could create a new array that’s one element shorter, and which contains all but the first element of the original array. The CopyTo method can’t help here as it copies the whole array, but you can use the more flexible Array.Copy method instead, as Example 7-19 shows.

static CalendarEvent[] RemoveFirstEvent(CalendarEvent[] events)
{
    CalendarEvent[] croppedEvents = new CalendarEvent[events.Length - 1];
    Array.Copy(
        events,              // Array from which to copy
        1,                   // Starting point in source array
        croppedEvents,       // Array into which to copy
        0,                   // Starting point in destination array
        events.Length - 1    // Number of elements to copy
        );
    return croppedEvents;
}

The key here is that we get to specify the index from which we want to start copying—1 in this case, skipping over the first element, which has an index of 0.

The topic of array sizes is a little more complex than it first appears, so let’s look at that in more detail.

As we said earlier, you can make an array using any type as the element type. And since arrays themselves have types, it follows that you can have an array of arrays. For example, suppose we wanted to create a list of forthcoming events over the next five days, grouped by day. We could represent this as an array with one entry per day, and since each day may have multiple events, each entry needs to be an array. Example 7-20 creates just such an array.

static CalendarEvent[][] GetEventsByDay(CalendarEvent[] allEvents,
                                        DateTime firstDay,
                                        int numberOfDays)
{
    CalendarEvent[][] eventsByDay = new CalendarEvent[numberOfDays][];

    for (int day = 0; day < numberOfDays; ++day)
    {
        DateTime dateOfInterest = (firstDay + TimeSpan.FromDays(day)).Date;
        CalendarEvent[] itemsOnDateOfInterest = Array.FindAll(allEvents,
            e => e.StartTime.Date == dateOfInterest);

        eventsByDay[day] = itemsOnDateOfInterest;
    }

    return eventsByDay;
}

We’ll look at this one piece at a time. First, there’s the method declaration:

static CalendarEvent[][] GetEventsByDay(CalendarEvent[] allEvents,
                                        DateTime firstDay,
                                        int numberOfDays)
{

The return type—CalendarEvent[][]—is an array of arrays, denoted by two pairs of square brackets. You’re free to go as deep as you like, by the way—it’s perfectly possible to have an array of arrays of arrays of arrays of anything.

The method’s arguments are fairly straightforward. This method expects to be passed a simple array containing an unstructured list of all the events. The method also needs to know which day we’d like to start from, and how many days we’re interested in.

The very first thing the method does is construct the array that it will eventually return:

CalendarEvent[][] eventsByDay = new CalendarEvent[numberOfDays][];

Just as new CalendarEvent[5] would create an array capable of containing five CalendarEvent elements, new CalendarEvent[5][] would create an array capable of containing five arrays of CalendarEvent objects. Since our method lets the caller specify the number of days, we pass that argument in as the size of the top-level array.

Remember that arrays are reference types, and that whenever you create a new array whose element type is a reference type, all the elements are initially null. So although our new eventsByDay array is capable of referring to an array for each day, what it holds right now is a null for each day. So the next bit of code is a loop that will populate the array:

for (int day = 0; day < numberOfDays; ++day)
{
    ...
}

Inside this loop, the first couple of lines are similar to the start of Example 7-14:

DateTime dateOfInterest = (firstDay + TimeSpan.FromDays(day)).Date;
CalendarEvent[] itemsOnDateOfInterest = Array.FindAll(allEvents,
    e => e.StartTime.Date == dateOfInterest);

The only difference is that this example calculates which date to look at as we progress through the loop. So Array.FindAll will return an array containing all the events that fall on the day for the current loop iteration. The final piece of code in the loop puts that into our array of arrays:

eventsByDay[day] = itemsOnDateOfInterest;

Once the loop is complete, we return the array:

    return eventsByDay;
}

Each element will contain an array with the events that fall on the relevant day.

Code that uses such an array can use the normal element access syntax, for example:

Console.WriteLine("Number of events on first day: " + eventsByDay[0].Length);

Notice that this code uses just a single index—this means we want to retrieve one of the arrays from our array of arrays. In this case, we’re looking at the size of the first of those arrays. Or we can dig further by providing multiple indexes:

Console.WriteLine("First day, second event: " + eventsByDay[0][1].Title);

This syntax, with its multiple sets of square brackets, fits right in with the syntax used to declare and construct the array of arrays.

So why is an array of arrays sometimes called a jagged array? Figure 7-4 shows the various objects you would end up with if you called the method in Example 7-20, passing the events from Example 7-10, asking for five days of events starting from July 11. The figure is laid out to show each child array as a row, and as you can see, the rows are not all the same length—the first couple of days have two items per row, the third day has one, and the last two are empty (i.e., they are zero-length arrays). So rather than looking like a neat rectangle of objects, the rows form a shape with a somewhat uneven or “jagged” righthand edge.

Figure 7-4. A jagged array

This jaggedness can be either a benefit or a problem, depending on your goals. In this example, it’s helpful—we used it to handle the fact that the number of events in our calendar may be different every day, and some days may have no events at all. But if you’re working with information that naturally fits into a rectangular structure (e.g., pixels in an image), rows of differing lengths would constitute an error—it would be better to use a data structure that doesn’t support such things, so you don’t have to work out how to handle such an error.

Moreover, jagged arrays end up with a relatively complicated structure—there are a lot of objects in Figure 7-4. Each array is an object distinct from the objects its element refers to, so we’ve ended up with 11 objects: the five events, the five per-day arrays (including two zero-length arrays), and then one array to hold those five arrays. In situations where you just don’t need this flexibility, there’s a simpler way to represent multiple rows: a rectangular array.

A rectangular array^[15] lets you store multidimensional data in a single array, rather than needing to create arrays of arrays. They are more regular in form than jagged arrays—in a two-dimensional rectangular array, every row has the same width.

Rectangular arrays tend to suit different problems than jagged arrays, so we need to switch temporarily to a different example. Suppose you were writing a simple game in which a character runs around a maze. And rather than going for a typical modern 3D game rendered from the point of view of the player, imagine something a bit more retro—a basic rendering of a top-down view, and where the walls of the maze all fit neatly onto a grid. If you’re too young to remember this sort of thing, Figure 7-5 gives a rough idea of what passed for high-tech entertainment back when your authors were at school.

Figure 7-5. Retro gaming—3D is for wimps

We don’t want to get too hung up on the details of the game play, so let’s just assume that our code needs to know where the walls are in order to work out where the player can or can’t move next, and whether she has a clean shot to take out the baddies chasing her through the maze. We could represent this as an array of numbers, where 0 represents a gap and 1 represents a wall, as Example 7-21 shows. (We could also have used bool instead of int as the element type, as there are only two possible options: a wall or no wall. However, using true and false would have prevented each row of data from fitting on a single row in this book, making it much harder to see how Example 7-21 reflects the map in Figure 7-5. Moreover, using numbers leaves open the option to add exciting game features such as unlockable doors, squares of instant death, and other classics.)

int[,] walls = new int[,]
{
    { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
    { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1 },
    { 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1 },
    { 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1 },
    { 1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 1 },
    { 1, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0 },
    { 1, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1 },
    { 1, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0, 1 },
    { 1, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 1 },
    { 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 1 },
    { 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1 },
    { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }
};

There are a couple of differences between this and previous examples. First, notice that the array type has a comma between the square brackets. The number of commas indicates how many dimensions we want—no commas at all would mean a one-dimensional array, which is what we’ve been using so far, but the single comma here specifies a two-dimensional array. We could represent a cuboid layout with int[,,], and so on, into as many dimensions as your application requires.

The second thing to notice here is that we’ve not had to use the new keyword for each row in the initializer list—new appears only once, and that’s because this really is just a single object despite being multidimensional. As Figure 7-6 illustrates, this kind of array has a much simpler structure than the two-dimensional jagged array in Figure 7-4.

The syntax for accessing elements in a rectangular array is slightly different from that of a jagged array. But like a jagged array, the access syntax is consistent with the declaration syntax—as Example 7-22 shows, we use a single pair of square brackets, passing in an index for each dimension, separated by commas.

Figure 7-6. A two-dimensional rectangular array

static bool CanCharacterMoveDown(int x, int y, int[,] walls)
{
    int newY = y + 1;

    // Can't move off the bottom of the map
    if (newY == walls.GetLength(0)) { return false; }

    // Can only move down if there's no wall in the way
    return walls[newY, x] == 0;
}

Example 7-22 performs two checks: before it looks to see if there’s a wall in the way of the game character, it first checks to see if the character is up against the edge of the map. To do this, it needs to know how big the map is. And rather than assuming a fixed-size grid, it asks the array for its size. But it can’t just use the Length property we saw earlier—that returns the total number of elements. Since this is a 12×12 array, Length will be 144. But we want to know the length in the vertical dimension. So instead, we use the GetLength method, which takes a single argument indicating which dimension you want—0 would be the vertical dimension and 1 in this case is horizontal.

This rectangular example has used a two-dimensional array of integers, and since int is a value type, the values get to live inside the array. You can also create multidimensional rectangular arrays with reference type elements. In that case, you’ll still get a single object containing all the elements of the array in all their dimensions, but these individual elements will be null references—you’ll need to create objects for them to refer to, just like you would with a single-dimensional array.

While jagged and rectangular multidimensional arrays give us flexibility in terms of how to specify the size of an array, we have not yet dealt with an irritating sizing problem mentioned back at the start of the chapter: an array’s size is fixed. We saw that it’s possible to work around this by creating new arrays and copying some or all of the old data across, or by getting the Array.Resize method to do that work for us. But these are inconvenient solutions, so in practice, we rarely work directly with arrays in C#. There’s a far easier way to work with changing collection sizes, thanks to the List<T> class.

The List<T> class gets no special privileges—it may be part of the .NET Framework class library, but it is subject to the same restrictions as your code. And so it has the same problem just described—the following code will produce the same compiler error you saw in the preceding section:

List<CanChange> numbers = new List<CanChange> { new CanChange() };
numbers[0].Number = 42;  // Will not compile

One way of dealing with this would be to avoid using custom value types in a collection class such as List<T>, preferring custom reference types instead. And that’s not a bad rule of thumb—reference types are a reasonable default choice for most data types. However, value types do offer one compelling feature if you happen to be dealing with very large volumes of data. As Figure 7-1 showed earlier, an array with reference type elements results in an object for the array itself, and one object for each element in the array. But when an array has value type elements, you end up with just one object—the values live inside the array, as Figure 7-3 illustrates. List<T> has similar characteristics because it uses an array internally.

For an array with hundreds of thousands of elements, the simpler structure of Figure 7-3 can have a noticeable impact on performance. For example, I just ran a quick test on my computer to see how long it would take to create a List<CanChange> with 500,000 entries, and then run through the list, adding the Number values together. Example 7-28 shows the code—it uses the Stopwatch class from the System.Diagnostics namespace, which provides a handy way to see how long things are taking.

Stopwatch sw = new Stopwatch();
sw.Start();
int itemCount = 500000;
List<CanChange> items = new List<CanChange>(itemCount);
for (int i = 0; i < itemCount; ++i)
{
    items.Add(new CanChange { Number = i });
}
sw.Stop();
Console.WriteLine("Creation: " + sw.ElapsedTicks);
sw.Reset();
sw.Start();
int total = 0;
for (int i = 0; i < itemCount; ++i)
{
    total += items[i].Number;
}
sw.Stop();
Console.WriteLine("Total: " + total);
Console.WriteLine("Sum: " + sw.ElapsedTicks);

With CanChange as a value type, it takes about 150 ms on my machine to populate the list, and then about 40 ms to run through all the numbers, adding them together. But if I change CanChange from a struct to a class (i.e., make it a reference type) the numbers become more like 600 ms and 50 ms, respectively. So that’s about 25 percent longer to perform the calculations but a staggering four times longer to create the collection in the first place. And that’s because with CanChange as a reference type, we now need to ask the .NET Framework to create half a million objects for us instead of just one object when we initialize the list. From the perspective of an end user, this is the difference between a tiny hiatus and an annoyingly long delay—when an application freezes for more than half a second, users begin to wonder if it has hung, which is very disruptive.

Since the use of value types in a collection can sometimes offer very useful performance benefits, the rule of thumb we suggested earlier—always use reference types—looks too restrictive in practice. So this is where immutability comes into play. As we saw earlier in this section, the fact that a get accessor can only return a copy of a value type causes problems if you ever need to modify a value already in a collection. But if your value types are immutable, you will never hit this problem. And as we’ll see in Chapter 16, there are other benefits to immutable types.

So we now know how List<T> is able to make itself resemble an array. Having understood some of the subtle differences between array element access and custom indexers, let’s get back to some of the other functionality of List<T>.

The AddNumbers method in Example 7-31 creates all of its output before it returns anything. We could describe it as being eager—it does all the work it might need to do right up front. But the modified version in Example 7-32, which uses yield return, is not so eager: it generates items only when it is asked for them, as you can see from the output of Example 7-33. This approach of not doing work until absolutely necessary is often referred to as a lazy style. In fact, if you look closely at the output you’ll see that the AddNumbers method in Example 7-33 is so lazy, it doesn’t seem to run any code at all until we start asking it for items—the Starting AddNumbers message printed out at the beginning of the AddNumbers method (before it starts its foreach loop) doesn’t appear when we call AddNumbers—as you can see, the Starting main loop message appears first, even though Main doesn’t print that out until after AddNumbers returns. This illustrates that none of the code in AddNumbers runs at the point when we call AddNumbers. Nothing happens until we start retrieving elements.

Lazy enumeration has some benefits, particularly if you are dealing with very large quantities of information. Lazy enumeration makes it possible to start processing data as soon as the first item becomes available. Example 7-34 illustrates this. Its GetAllFilesInDirectory returns an enumeration that returns all the files in a folder, including all those in any subdirectories. The Main method here uses this to enumerate all the files on the C: drive. (In fact, the Directory class can save us from writing all this code—there’s an overload of Directory.EnumerateFiles that will do a lazy, recursive search for you. But writing our own version is a good way to see how lazy enumeration works.)

class Program
{
    static IEnumerable<string> GetAllFilesInDirectory(string directoryPath)
    {
        IEnumerable<string> files = null;
        IEnumerable<string> subdirectories = null;
        try
        {
            files = Directory.EnumerateFiles(directoryPath);
            subdirectories = Directory.EnumerateDirectories(directoryPath);
        }
        catch (UnauthorizedAccessException)
        {
            Console.WriteLine("No permission to access " + directoryPath);
        }
        if (files != null)
        {
            foreach (string file in files)
            {
                yield return file;
            }
        }
        if (subdirectories != null)
        {
            foreach (string subdirectory in subdirectories)
            {
                foreach (string file in GetAllFilesInDirectory(subdirectory))
                {
                    yield return file;
                }
            }
        }
    }

    static void Main(string[] args)
    {
        foreach (string file in GetAllFilesInDirectory(@"c:"))
        {
            Console.WriteLine(file);
        }
    }
}

If you run this, you’ll find it starts printing out filenames immediately, even though it clearly won’t have had time to discover every single file on the hard disk. (That’s why we’re not using the overload of Directory.GetFiles that recursively searches subdirectories for us. As you’ll see in Chapter 8, the Directory class can save us from writing all this code, but it insists on finding all the files before starting to return any of them.)

It’s possible to chain enumerations together. For example, we can combine Example 7-34 with the AddNumbers function, as shown in Example 7-35.

IEnumerable<string> allFiles = GetAllFilesInDirectory(@"c:");
IEnumerable<string> numberedFiles = AddNumbers(allFiles);
foreach (string file in numberedFiles)
{
    Console.WriteLine(file);
}

If we’re using the version of AddNumbers from Example 7-32—the one that uses yield return—this will start printing out filenames (with added numbers) immediately. However, if you try it with the version from Example 7-31, you’ll see something quite different. The program will sit there for as many minutes as it takes to find all the filenames on the hard disk—it might print out some messages to indicate that you don’t have permission to access certain folders, but it won’t print out any filenames until it has all of them. And it ends up consuming quite a lot of memory—on my system it uses more than 130 MB of memory, as it builds up a huge List<string> containing all of the filenames, whereas the lazy version makes do with a rather more frugal 7 MB.

So in its eagerness to do all of the necessary work up front, Example 7-31 actually slowed us down. It didn’t return any information until it had collected all of the information. Ironically, the lazy version in Example 7-32 enabled us to get to work much faster, and to work more efficiently.

Lazy enumeration also permits an interesting technique whereby infinite loops aren’t necessarily a problem. A method can yield an infinite collection, leaving it up to the caller to decide when to stop. Example 7-36 returns an enumeration of numbers in the Fibonacci series. That’s an infinite series, and since this example uses the BigInteger type introduced in .NET 4, the quantity of numbers it can return is limited only by space and time—the amount of memory in the computer, and the impending heat death of the universe, respectively (or your computer’s next reboot, whichever comes sooner).

using System.Numerics; // Required for BigInteger

...

static IEnumerable<BigInteger> Fibonacci()
{
    BigInteger current = 1;
    BigInteger previous = 1;
    yield return 1;
    while (true)
    {
        yield return current;
        BigInteger next = current + previous;
        previous = current;
        current = next;
    }
}

Because consumers of enumerations are free to stop enumerating at any time, in practice this sort of enumeration will just keep going until the calling code decides to stop. We’ll see some slightly more practical uses for this when we explore parallel execution and multithreading later in the book.

The concept of chaining lazy enumerations together shown in Example 7-35 is a very useful technique—it’s the basis of the most powerful feature that was added in version 3 of C#: LINQ. LINQ is such an important topic that the next chapter is devoted to it. But before we move on, let’s review what we’ve seen so far.