IDisposable

MergeSort and LINQ

2010-10-24T15:11:00.000-07:00

Here is an implementation of the merge sort algorithm, which operates on a sequence/list of items:


using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace MergeSort
{
    public static class MergeSort_Extensions
    {
        public static IEnumerable<T> MergeSort<T>(this IList<T> items, Comparison<T> comparison)
        {
            return MergeSortInternal<T>(items, items.Count, comparison);
        }

        public static IEnumerable<T> MergeSort<T>(this IEnumerable<T> items, Comparison<T> comparison)
        {
            return MergeSortInternal<T>(items, items.Count(), comparison);
        }

        private static IEnumerable<T> MergeSortInternal<T>(IEnumerable<T> items, int count, Comparison<T> comparison)
        {
            Debug.Assert(items != null);
            Debug.Assert(comparison != null);

            if (count == 0)
                yield break;

            if (count == 1)
            {
                yield return items.First();
                yield break;
            }

            // sort both halves recursively
            IEnumerator<T> enumA = MergeSortInternal<T>(items.Take<T>(count / 2), count / 2, comparison).GetEnumerator();
            IEnumerator<T> enumB = MergeSortInternal<T>(items.Skip<T>(count / 2), count - count / 2, comparison).GetEnumerator();

            bool movedA = enumA.MoveNext();
            bool movedB = enumB.MoveNext();
            Debug.Assert(movedA && movedB);

            // merge
            while (true)
            {
                if (comparison(enumA.Current, enumB.Current) > 0)
                {
                    // swap enumerators
                    IEnumerator<T> iterTemp = enumA;
                    enumA = enumB;
                    enumB = iterTemp;
                }

                yield return enumA.Current;
                if (enumA.MoveNext() == false)
                {
                    // return the remaining items
                    do yield return enumB.Current;
                    while (enumB.MoveNext());
                    break;
                }
            }
        }
    }
}

P.S. The code was formatted with http://formatmysourcecode.blogspot.com/

Would you not? Yes or No?

2008-07-07T15:17:00.000-07:00

Below is a screenshot of a website (odnoklassniki.ru), which demonstrates a wonderful UI principle of confusing the user. It translates: "Confirmation: Do you, really, not want to receive notifications of the changes in the group? [Yes] [No]"..

I remember, I knew exactly what I wanted before I was asked... Now I'm not so sure, really :-)

Virtual Machito

2008-07-07T15:13:00.000-07:00

Vista can be puzzling at times.. For example, while I was copying files from "D:\Virtual Machines" directory, it caught my eye that the progress dialog was showing something else - "D:\Virtual Machito":

Very cute :-)

Google "facker"

2008-07-07T15:08:00.001-07:00

While signing up for a new Google account, I was asked, as a proof that I'm human, to enter a Captcha-word "facker":

Hilarious.. and just facking-awesome! :-)

PicasaWeb sucks (life out of photographs)

2008-07-07T14:28:00.000-07:00

I had a long-running suspicion that images uploaded to PicasaWeb don't look good in the browser when viewed at full zoom (via the tiny "zoom" button). Finally, I got some proof. Here is the small crop of a 2400x1600 photograph:

As you can see, the image presented by PicasaWeb in the browser lost its sharpness and detail. The results are quite disappointing... Could this be the right time to move to Flickr?

A Million Little Rows

2008-06-02T14:38:00.000-07:00

Some time ago, I found this handy T-SQL script on the Web, which creates a table with a million rows (1, 2, 3, ... 999999, 1000000):


-- Declare a variable to hold the
-- count of rows to be generated
Declare @p_NumberOfRows Bigint

-- We need 1 million rows
Select @p_NumberOfRows=1000000;

With Base As
(
    Select 1 as n
    Union All
    Select n+1 From Base Where n < Ceiling(SQRT(@p_NumberOfRows))
),
Expand As
(
    Select 1 as C
    From Base as B1, Base as B2
),
Nums As
(
    Select Row_Number() OVER(ORDER BY C) As n
    From Expand
)
Select n into BigTable from Nums Where n<=@p_NumberOfRows

-- Remove Maximum Recursion level constraint
OPTION (MaxRecursion 0);

It runs great with Microsoft SQL Server 2005.

Dispose Design Pattern

2008-06-01T11:14:00.000-07:00

Given all the benefits of the Garbage Collector (GC) in .NET, the IDisposable/Dispose pattern is a necessary evil. It does make the code more complicated, harder to manage, and more error-prone. However, if you want to rely solely on finalizers to release resources, your application isn't going to fly.

Releasing resources (database connections, handles to open files, blocks of memory, etc.) as soon as they are no longer needed is prudent. Also, dropping the references to other objects is a great idea, because it helps the GC reclaim unused memory more efficiently. For the GC, the more null references, the better.

To reiterate, the Dispose() method should be used to:

Release managed resources (in the realm of CLR);
Release unmanaged resources (in the native realm);
Drop references (set them to null).

There is one fortunate side-effect of the IDisposable pattern: it may be used for canceling pending asynchronous operations. Imagine a database query form, which can be closed by a user any moment. The best way to handle this situation is to implement the Dispose method on a class that performs the asynchronous query, which would close database connections, effectively, canceling the database request. One thing to note here is that in this scenario, concurrency comes into play, since Dispose may be invoked simultaneously with the async callbacks.

Thus, Dispose() may also be used to:

Cancel any pending async operations.

What are finalizers good for then? Since finalizers are not guaranteed to execute at all, and they impose a considerable overhead onto the GC - the answer is: pretty much nothing. According to MSDN, finalizers should be used to release unmanaged resources. There is another school of thought, which suggests to not use finalizers at all. In the context of our discussion, however, there is one beneficial use of finalizers:

To warn if the Dispose() method hasn't been called (via asserting or logging).

It should be self-evident from the failed assertion, who was responsible for disposing of the object properly. To make it even more apparent, one could capture the callstack in the constructor, which would identify the object's creator. The GC overhead can be avoided in the correct use-case by hinting the GC to skip the finalizer with the SuppressFinalize method.

There is an IDisposable pattern (C# .NET) posted on MSDN. I personally prefer the following variation:


using System;
using System.Diagnostics;

namespace MyProject
{
  class MyClass:
      IDisposable
  {
      ~MyClass()
      {
          DisposeOfUnmanagedResources();

          // should have called Dispose!
          Debug.Assert(false);
      }

      public void Dispose()
      {
          DisposeOfUnmanagedResources();
          
          // release managed resources

          GC.SuppressFinalize(this);
      }

      private void DisposeOfUnmanagedResources()
      {
          // release unmanaged resources
      }
  }
}

(The sample above was formatted using http://www.manoli.net/csharpformat/)

Compared to the original pattern on MSDN, here:

DisposeOfManagedResources()/DisposeOfUnmanagedResources() replace the ambiguous Dispose(bool) method;
The finalizer ~MyClass() would raise an assertion (in Debug builds) if the user of MyClass hasn't called Dispose().

That's it.