jaredpar's WebLog : VB

Dev Connection Talk Slides and Code

Jared Parsons — Wed, 02 Dec 2009 21:21:45 GMT

Thanks to everyone who attended my sessions at Dev Connections. I’ve posted the material for both of my talks on my SkyDrive account. This includes the slides and projects.

http://cid-dc25b20f65f628f8.skydrive.live.com/browse.aspx/Public/DevConnections2009

Please let me know if you have any questions or problems with the materials or any additional feedback about the sessions.

Speaking at Dev Connections in Las Vegas Next Week

Jared Parsons — Tue, 03 Nov 2009 16:51:04 GMT

Next week I will be speaking at Dev Connections in Las Vegas. I will be running the following sessions

VMS02: Future Directions for Visual Basic
VMS04: Microsoft Visual Basic IDE Tips and Tricks

Both of these talks will spend a bit of time talking about all of the progress and exciting new features we’ve added in Dev10. Given I primarily work on the IDE these days, expect a bit of IDE content to work it’s way into the Future Directions talk as well.

Why is LINQ absent from debugger windows?

Jared Parsons — Wed, 26 Aug 2009 15:00:00 GMT

As the owner of the VB.Net portion of the overall debugging experience, I frequently hear the request from customers to add LINQ support into the Watch / Immediate and Locals window. Virtually every other type of expression is available in the debugger windows so why leave one of the most popular ones out?

Quick Diversion: the specifics of this article are written from the point of view of the VB.Net expression evaluator. However, the limitations blocking LINQ support (in both the architecture and overall design) are very similar between VB.Net and C#.

As usual, the primary issue is cost and the cost for LINQ in the debugger windows is very high. To understand why the cost is so high though, we must start by getting a better understanding how a language service interacts with the debugging services of Visual Studio and the general philosophy around compiler features in the debugger.

Languages in Visual Studio typically provide the following major components to support the debugging experience.

Expression Evaluator (EE): This is the language specific component which provides all of the data used in the watch, locals and immediate window, data tips, conditional breakpoints and several other components. It’s primary input is an expression in string form which is converted to a value (typically an ICorDebugValue instance) and outputs a COM object capable of inspecting that value to the core debugger [1]. Everything typed into the debugger windows goes through the EE.

This component lives in the MTA of Visual Studio and has almost no interaction with the UI / STA thread.
ENC Service: This is the component which is the work horse of ENC operations. It provides rude edit detection, metadata differencing and metadata + IL generation .

This component lives in the main STA of Visual Studio

The important thing to understand about the expression evaluator is that it’s purpose is primarily to provide an expression evaluation and data inspection service. How expression evaluation works is an article in itself but suffice it to say that it converts the string to a very low level AST then walks the nodes bottom up and evaluating the expressions using the ICorDebug APIs. The EE component has no UI and is simply a data provider for the core debugger services.

The design philosophy for Both VB.Net and C# is to have the highest level of fidelity between expressions evaluated in the EE and the actual running program. To do otherwise would lead to extremely confusing results for users. When spec’ing feature support in the VB.Net EE we start from the point of 100% fidelity, determine the problems with this design (if any) and then start the difficult process of making compromises.

LINQ expressions are very different than any other expression previously allowed in the EE window because of the features interaction with metadata. All LINQ expressions require the generation or manipulation of metadata to support the underlying lambda and/or closure. Adding support for this is one of the biggest hurdles to getting LINQ (and other features) into the EE.

Evaluating a LINQ expression is actually much closer to an ENC operation than a traditional EE one.

Currently the EE’s have no capacity for generating metadata, only interpreting it. Operations which mutate or generate metadata have traditionally only been allowed via the ENC service. Getting LINQ to work in the EE with true fidelity would require at least a minimal amount of ENC feature work.

Without getting into too much detail, lets enumerate the new major features necessary to evaluate a LINQ expression in the EE with true fidelity to the running program. To simplify things, we’ll start by assuming there is no other LINQ expression used in the current method and the method is only being executed at most once at any given time in the process.

A metadata generation service to support the backing for closures and lambda expressions
Convert expressions typed in the EE into IL [2]
ENC support for metadata to push the new metadata for closures and lambdas into the currently executing assembly
ENC support for method body IL to remove lifted variables from the current method and redirect the references inside the closure

Issues #1 and #2 are for the most part internal architecture issues and can be solved via normal processes of code base refactoring and adding new features to an existing component. I don’t mean to imply these problems are cheap (in fact they are relatively expensive) But fixing these is somewhat of an understood quantity.

Issues #3 and #4 are where the problems start. As implemented EE’s do not have capability to create or modify metadata in the running process (that is the job of the ENC service). EE’s do have access to the underlying CLR ENC APIs so it is possible to implement ENC operations in the EE. It’s just simply not been done yet.

Wait! Why not reuse our ENC implementation in the EE? Unfortunately the ENC service is currently tied heavily to our in memory IDE compiler and many other IDE / STA features. It in fact lives in a completely separate DLL, separate COM apartment and works on a different symbol table than the EE.

More fundamental though is that it’s designed for a completely different purpose. ENC is designed to track edits in live code, determining the differences and applying them to the running program. The hypothetical EE feature would be tracking expressions that modify a running DLL for which code is not guaranteed (and not likely) to be available and applying the difference to the running program. There are some similarities but the differences are significant enough to make code reuse have limited value.

Some people may wonder why it’s necessary to implement #4. Couldn’t we just avoid removing the variable from the current method and make the feature cheaper? This is possible but it would cause a significant fidelity difference in the feature. Any mutations of the local variable within the LINQ expression would not be visible on the stack frame as it would if the LINQ expression was present in the original program.

It’s easy to think of this ENC in the EE as just the same type of cost as #1 and #2 (in many ways it is). However taking advantage of the CLR ENC APIs in the EE also means that we inherit it’s limitations as well. ENC as as implemented in the CLR has many limitations which fly in the face of LINQ. In particular the following ENC limitations present major problems (ENC limitations reference).

Cannot add members to a value type. This prevents evaluating LINQ when stopped in a value type method
Cannot remove locals from a function. This is an implementation of LINQ but we could work around this problem by changing the IL to simply no longer accessing the local variables.
Cannot change anything in a generic type. This prevents evaluating LINQ when stopped in a generic type.
Cannot specify an initial value for newly added fields.
Allowable ENC operations differ between the top of the stack and operations elsewhere within the stack
Modification of a non-top stack frame cannot significantly edit the current function call. So if a LINQ expression captures a variable used in that call (think ref passing) it would likely be unable to be evaluated.

So even if we implemented everything possible on the language service side the resulting feature would be limited in several impactful ways. Additionally these limitations are somewhat orthogonal to the current limitations EE’s face and would require a bit of user education. And this is only for the most basic LINQ feature under unrealistic scenarios.

Lets now consider the problems of evaluating a LINQ expression when the current method already contains a LINQ expression that lifts at least 1 variable. Evaluating a new expression at the same scope would require the modification of the current closure to maintain fidelity as opposed to generating a new one. This brings along with it a couple more problems.

A lambda expression which uses 2 variables, 1 of which is captured in an existing lambda expression. To maintain fidelity we would have to modify an existing closure signature to contain the new variable.

Often times generated closures are generic so we would run straight into ENC limitation #3. Additionally we would need the newly added field to have the same value as it has in the current method which runs us into ENC limitation #4. Now also consider that a closure instance can live much longer than the method in which it was created. For those closures no stack value is available so what value should we give fields in that instance? Ideally it should have the value of the variable at the point the method exited but realistically that’s not possible.
A lambda expression which uses 1 variable in a method where an existing lambda expression captures that same variable and another. To maintain fidelity we would have to know about this and fake capture the second variable as well.

Now consider all of the problems above and consider the scenario where there are multiple threads and multiple instances of the current method active in the program. How to determine which closure instance belongs to which thread, and just as important which stack frame on which thread, with respect to initializing values?

None of the issues are an unsolvable problem but they do represent a significant cost to the feature. And once again even if we added all of these features to the EE, ENC limitations would significantly limit the usefulness of the resulting feature.

Does this mean that LINQ, or any future metadata requiring expression, will never be added to the debugger window? Absolutely not. We’ve just hit the difficult stage of making compromises on the level of fidelity in the feature. If you back off of true fidelity in a few small ways the resulting feature, while still very expensive, is significantly cheaper and removes many of the limitations imposed by ENC. This hypothetical feature will be discussed in my next article.

[1] For those interested the returned interface is IDebugProperty2

[2] Right now expressions are converted to a tree form slightly above IL and they are interpreted using the ICorDebug APIs. Converting all the way down to IL requires a lot more work

Extension Methods and ByRef targets

Jared Parsons — Thu, 11 Dec 2008 16:00:00 GMT

One of the seldom used, and often unknown, features of VB extension methods is that the argument of the extension method (the first parameter) can be passed by reference. This gives extension methods the power to change the reference that was used to invoke the value!

Obviously this can produce unexpected but often amusing behavior. The following sample prints “False”.

    <Extension()> _
    Public Sub EnsureNotNull(ByRef str As String)
        If str Is Nothing Then
            str = String.Empty
        End If
    End Sub

    Sub Example(ByVal p1 As String)
        p1.EnsureNotNull()
        Console.WriteLine("{0}", p1 Is Nothing)
    End Sub

    Sub Main()
        Example(Nothing)
    End Sub

I think people will look at this example and either cringe, call it terrible code or get excited. Personally I’m somewhere between cringing and getting excited (in fact I’m doing both). But before people think I’ve gone off the deep end I don’t plan on checking this in any time soon (and yes I think it’s a bad idea).

Why? The feature is fun to play with and can create some interesting samples but it can also just as easily lead to very bad and unanticipated behavior. For instance what if instead of making sure something wasn’t Nothing, the code made the argument Nothing?

<Extension()> _
Sub EvilMethod(ByRef p1 As Object)
    p1 = Nothing
End Sub

Sub Example2()
    Dim s As New Student()
    s.PrintClass()
    s.EvilMethod()
    s.PrintName()   ' Causes a NullReferenceException
End Sub

The code runs and throws an exception. A developer attaches a debugger, looks at the exception but immediately notes there are 2 other method calls just above. How could they succeed but the last throw a NullReferenceException??? Certainly this may be a fun joke but in production code a fellow developer would not be amused.

More importantly though the behavior when passing an extension method target by reference is flat out unexpected. Who expects what appears to an instance method call to be able to modify “Me/this?” Probably not too many people. Coding is difficult enough without creating patterns that will blow away anyone who owns your code down the line. Code should do it’s best to be clear and produce predictable results.

Still, an interesting feature to toy with.

Properly handling a WinForms Timer event

Jared Parsons — Mon, 27 Oct 2008 15:00:07 GMT

The WinForms Timer class allows the user to perform a particular action at a set interval. Timer objects fire a Tick event at the set time which users can easily respond to. This is very useful if a developer wants to check for a particular condition say every 2 seconds ( for the remainder of this article I'm going to use 2 seconds as a practical example even though it's really any arbitrary time period).

Occasionally users are surprised to find that the Tick event will fire much faster than they are expecting. Instead of waiting for 2 seconds between calls, they event will fire almost immediately after one is finished processing.

What's going on here is a side effect of how this event works under the hood. The interval for the timer event is calculated in real world time. So quite literally every 2 seconds Windows will consider the internal reached and will issue a new tick message. The next time a WinForms event is not executing developer code a tick event is raised [1].

So imagine we had the following code.

Private Sub OnTimerTick() Handles m_timer.Tick
    RunSomeOperation()
End Sub

Consider what happens if RunSomeOperation takes longer than 2 seconds. The Tick event is fired in real time so while we're in the middle of RunSomeOperation, another Tick event is being queued up for processing. As soon as we leave OnTimerTick we're back in WinForms code which sees a Tick event and promptly raises it which puts us right back in OnTimerTick.

This is contrary to what most people expect. Most people expect the Tick event to fire 2 seconds after their code is finished executing.

To work around this developers should stop the timer when processing a timer event. Just before exiting the event handler, re-enable the timer. This will cause Windows to start calculating the interval from the start. This has the effect of making the timer event fire 2 seconds after developer code stops executing.

Private Sub OnTimerTick() Handles m_timer.Tick
    m_timer.Stop()
    Try
        RunSomeOperation()
    Finally
        m_timer.Start()
    End Try
End Sub

[1] This is not 100% true. It's really whenever the Application begins to pump messages again. Message pumping, more specifically when it does and does not occur, is too involved for this discussion.

VB Catch ... When: Why so special?

Jared Parsons — Thu, 09 Oct 2008 15:00:00 GMT

The VB Catch syntax has a particular feature not present in C#: When. It allows users to filter expressions based on something other than their type. Any arbitrary code can enter a When block to decide whether or not to handle an Exception

    Sub Sub1()
        Try
            DoSomeAction()
        Catch ex As Exception When Filter(ex)
            Stop
        End Try
    End Sub

Newsgroups often ask, "Why's this so special? I could effectively get the same behavior out of C# by doing the following."

static void Sub1()
{
    try
    {
        DoSomeAction();
    }
    catch (Exception ex)
    {
        if (Filter(ex))
        {
            throw;
        }
        HandleException();
    }
}

This is true to an extent. In both cases the code is handling an exception and making a decision, via calling Filter, as to whether or not to handle the exception. The subtle difference is when the Filter method is called.

In VB the When statement is actually implemented as an IL exception filter. When an exception is thrown, exception filters are processed before the stack is unwound. This means that if the Filter method created an error report that included the current stack trace, it would show the frame in which the exception occurred.

For example, in the code above if DoSomeAction() threw and the stack was examined in the Filter expression, the following stack would show up.

Notice how the DoSomeAction method is clearly visible? This is incredibly powerful for features like error reporting and investigation. It also allows you to set powerful breakpoints where the exact state of the error can be examined and not just the post mortem.

Alternatively, code executed in the C# block will occur after the stack is unwound. This gets rid of the culprit. As long as your not in optimized code you can usually use the stack trace properties to get the source of the exception but you won't be able to examine the live state of the error.

First MSDN article

Jared Parsons — Mon, 18 Aug 2008 15:00:10 GMT

The August issue of MSDN magazine will be carrying an article I wrote this spring. In it I toy around with using the deferred execution and lazy evaluation properties of LINQ to create more responsive UI code.

You can view the article here.

As usual I appreciate any feedback you have.

Making Equality easier

Jared Parsons — Tue, 03 Jun 2008 15:00:10 GMT

Recently I've done a bit of posting about the difficulties of properly implementing equality in VB (and DotNet in general). While most of the problems can be fixed with a standard snippet the one really hard to implement issue is GetHashCode(). The rules for GetHashCode() are both simple and seemingly contradictory

If two objects are equal (via Equals) their GetHashCode() should be equal
GetHashCode() shouldn't ever change

These rules imply that GetHashCode() is related to Equality. At a fundamental level though GetHashCode has nothing to do with Equality. Instead it is linked to bucketing and ultimately any hashing sturcture such as Dictionary, Hashtable, etc ...

Unfortunately it is impossible to separate these two from an API perspective because it is ingrained into the BCL. There is a way to separate this out at a functionality level and still satisfy all of the rules of the GetHashCode() and Equals()

    Public Overrides Function GetHashCode() As Integer
        Return 1
    End Function

This absolutely maintains both of the rules for GetHashCode(). This allows you to completely separate Equality and GetHashCode() in your implementation while not breaking any BCL rules or assumptions.

Of course this does come with a trade off. As said before GetHashCode() is primarily used as a bucketing mechanism. It will cause the performance of bucketing collections such as Dictionary or Hashtable to drop from close to O(1) to O(N). But once again this is not a bug but a conscious trade off.

Equality isn't easy

Jared Parsons — Mon, 12 May 2008 15:00:20 GMT

After my recent postings on the rules of Equality, I thought it would be a good idea to post a simple example of equality. The class in question, Example, has only one field of type Integer name m_field1. Two instances of Example are equal if m_field1 has the same value. So the real equality check is just a single Integer comparison.

Unfortunately, as my posts alluded to, even though the check is simple getting it right is not necessarily so. The equality portion of example takes roughly 20 lines of code while the actual equality check represents only 1 of those lines [1]. Not a good ratio. The good and bad news about the other 19 lines is they are boiler plate so once you know them you don't have to think about them. For my own purposes I've converted those 19 lines into a snippet which automates the process but doesn't make it any easier on the eye.

Class Example
    Implements IEquatable(Of Example)

    Private ReadOnly m_field1 As Integer
    Public Sub New(ByVal field As Integer)
        m_field1 = field
    End Sub

    Public Function Equals1(ByVal other As Example) As Boolean Implements System.IEquatable(Of Example).Equals
        If other Is Nothing Then
            Return False
        End If

        Return m_field1 = other.m_field1
    End Function

    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Return Equals1(TryCast(obj, Example))
    End Function

    Public Overrides Function GetHashCode() As Integer
        Return m_field1.GetHashCode
    End Function

    Public Shared Operator =(ByVal left As Example, ByVal right As Example) As Boolean
        Return EqualityComparer(Of Example).Default.Equals(left, right)
    End Operator

    Public Shared Operator <>(ByVal left As Example, ByVal right As Example) As Boolean
        Return Not EqualityComparer(Of Example).Default.Equals(left, right)
    End Operator

End Class

Module Module1

    Sub AssertTrue(ByVal cond As Boolean)
        Debug.Assert(cond, "failure")
    End Sub

    Sub AssertFalse(ByVal cond As Boolean)
        Debug.Assert(Not cond, "failure")
    End Sub

    Sub Main()
        Dim v1 As New Example(1)
        Dim v2 As New Example(2)
        Dim v3 As New Example(1)

        AssertFalse(v1 Is v2)
        AssertFalse(v1 Is v3)
        AssertTrue(v1 Is v1)
        AssertFalse(v1 = v2)
        AssertTrue(v1 = v3)
        AssertFalse(v1 = Nothing)
        AssertFalse(Nothing = v1)
        AssertTrue(v1 <> v2)
        AssertTrue(v1 <> Nothing)
        AssertTrue(EqualityComparer(Of Example).Default.Equals(v1, v3))
        AssertFalse(EqualityComparer(Of Example).Default.Equals(v1, v2))
    End Sub

End Module

[1] Before VB criticism enters, C# has roughly the same ratio for the same sample.

IEquatable(Of T) and GetHashCode()

Jared Parsons — Fri, 09 May 2008 15:00:53 GMT

This is a bit of a follow up to a previous post we discussed how to properly implement equality in VB. Several users commented/asked that IEquatable(Of T) could be used in place of overriding Equals(). Since IEquatable(Of T) doesn't define a GetHashCode() method the user didn't need to define it and hence run into all of the problems associated with GetHashCode() usage.

Unfortunately this is not the case. Several parts of the framework link IEquatable(Of T).Equals and Object.GetHashCode() in the same way that Object.Equals() and Object.GetHashCode() are linked.

The prime example of this is EqualityComparer(Of T). This class is used to provide instances of IEqualityComparer(Of T) for any given type. Under the hood it tries to determine the best way checking for equality in types. If T implements IEquatable(Of T) it will eventually create an instance of GenericEqualityComparer(Of T) [1]. The methods of IEqualityComparer(Of T) are implemented as follows (boundary cases removed)

Equals(left, right): return left.Equals(right)

Equals in this case is IEquatable(Of T).Equals

GetHashCode(obj): return obj.GetHashCode()

This implicitly links IEquatable(Of T).Equals to Object.GetHashCode(). Therefore if you implement IEquatable(Of T) you should also override GetHashCode(). The best way to view this is "if you implement IEquatable(Of T) you should override Equals and GetHashCode."

What's even more unfortunate is there is no feedback to indicate this relationship exists. If you override Equals or GetHashCode both the C# and VB compilers will issue a warning/error. Implementing IEquatable(Of T) produces no such warning.

[1] Unfortunately this is a private type so you will need to use Reflector to view the type.

Properly Implementing Equality in VB

Jared Parsons — Mon, 28 Apr 2008 15:04:06 GMT

Many developers want to implement equality functions for their objects. DotNet made equality a deep part of the framework and added support all the way up to System.Object with Equals and GetHashCode. In addition to the strongly enforced method semantics of GetHashCode and Equals there are also several other hard to enforce patterns that developers must follow in order to properly integrate into the rest of the DotNet framework. We'll explore those rules today.

Before even talking about how to implement equality we need to define the types of equality.

Reference equality: Are these two objects really the exact same object.
Object/value equality: Depends on what the object author thinks equality means. Can be anything from reference equality up to, comparing fields, to were they created in the same app domain.

In VB these are two very separate types of equality. Reference equality is expressed through the "Is" operator. Object equality is done directly through operator=, operator<> and Equals. This is also indirectly exposed via GetHashCode, EqualityComparer(Of T) and other framework patterns.

When implementing object/value Equality there are four methods that are important to consider in order to fit expected patterns. What's even more important is understanding which ones must be implemented together. If an author overrides any of the functions in the following pairs they must override both.

Equals/GetHashCode
Operator=/Operator!=

To make it easier, my rule of thumb is to override all four or none.

Equals

This is the bread and butter of object/value equality. The author has free reign to decide what is and what is not equal. However there are a few rules authors must follow in order to fit into the rest of the framework.

Do not throw an exception from Equals. Many components call Equals in a loop and there is no way for them to handle or recover from an exception. If the object is not equal just return False
The object passed in is typed to object. It is perfectly valid for the framework to pass in an object that is completely unrelated to the type defining Equals. The type author must account for and handle this case.
The framework can pass in Nothing as a parameter to Equals and this is valid.

#2 and #3 may seem a bit off at first but it is implemented with a standard pattern as seen below.

Class C1
    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Dim other = TryCast(obj, C1)
        If other Is Nothing Then
            Return False
        End If
        ...
    End Function
End Class

It's very important that you use "Is" to compare other in the above example. Imagine if you slip up and type "=" instead. You're about to override Operator= and this will cause "other=Nothing" to call operator=. If this is a valid C1 instance operator= will almost certainly call Equals and then you'd have a stack overflow. Our implementation of Operator= below will avoid this problem.

GetHashCode

This is both the easiest and trickiest function to override because it has very subtle semantics which cause very hard to find bugs in code. The simple rule is "If two objects are equal in the sense of value equality they must return the same value in GetHashCode()".

Why? Many classes use the hash code to classify an object. In particular hash tables and dictionaries tend to place objects in buckets based on their hash code. When checking if an object is already in the hash table it will first look for it in a bucket. If two objects are equal but have different hash codes they may be put into different buckets and the dictionary would fail to lookup the object.

The better version of the GetHashCode rule has a small suffix on the simple rule. "Only calculate the hash code based off of primitive fields which are ReadOnly". This is not an absolute requirement as long as you are careful when you are code. But as previously stated, when coding it's best not to trust yourself to do the right thing. Not doing this will get you into trouble when dealing with Hashtables and dictionaries.

For instance take this not so small example. In this case value equality is based solely off of Field1 which is a modifiable field. Once Field1 is changed you may or may not be able to access the value in the dictionary because GetHashCode() will change. This example is contrived but it does happen in the real world and it can be incredibly difficult to track down.

Class C2
    Public Field1 As Integer

    Public Sub New(ByVal f1 As Integer)
        Field1 = f1
    End Sub
    Public Overrides Function GetHashCode() As Integer
        Return Field1.GetHashCode()
    End Function
    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Dim other = TryCast(obj, C2)
        If other Is Nothing Then
            Return False
        End If
        Return other.Field1 = Field1
    End Function
End Class

Module Module1

    Sub Main()
        Dim map = New Dictionary(Of C2, String)
        Dim v1 = New C2(44)
        map.Add(v1, "avalue")
        Console.WriteLine(map(v1))
        v1.Field1 = 2
        Console.WriteLine(map(v1))  ' Potentially throws
    End Sub

End Module

If Field1 were ReadOnly there would be no way to hit this problem. Then again we'd also not be able to change Field1.

Operator=

When implementing equality overriding operator= allows you to use the more pleasant and reliable version of syntax comparison: a=b vs. a.Equals(b). I say more reliable because using a.Equals(b) has an inherent dependency on "a" being a non-Nothing object. "Operator=" makes no assumption and should operate correctly in the presence of Nothing.

Operator= has virtually the same rules as Equals. Mainly don't throw from operator=. Operator= is usually just defined in terms of Equals() and since it also has to respect the no throw rule once we get there we are in good shape. Getting to Equals() can be tricky though because one or both of the arguments can be Nothing. In addition make sure not to use "=" to check for Nothing because you're back to the stack overflow problem.

What's great here is there is a simple solution that you should use every time you define Operator=. EqualityComparer(Of T) knows all of these rules and in the face of both parameters being non-Nothing will call Equals() just like we want. This makes the definition of Operator= boiler plate (I define very Operator= the exact same way)

Public Shared Operator =(ByVal left As C2, ByVal right As C2) As Boolean
    Return EqualityComparer(Of C2).Default.Equals(left, right)
End Operator

What's even better is that EqualityComparer(Of T) understands the stack overflow problem which can occur in equality comparison and avoids it.

Operator <>

Operator<> has the same rules as Operator= and luckily the same easy type of answer.

Public Shared Operator <>(ByVal left As C2, ByVal right As C2) As Boolean
    Return Not EqualityComparer(Of C2).Default.Equals(left, right)
End Operator

Wrapping Up

I started this article thinking it would be a few paragraphs of simple rules. But as I kept going I kept remembering the subtleties and problems I encountered in the past.

For my own projects I avoid implementing equality unless it's truly needed because of the problems with properly implementing GetHashCode(). The one exception is when I define immutable objects. Immutable objects have no problems with GetHashCode() since they are unchangable so Equality is straight forward.

Me, MyBase, MyClass and MyPost on the subject

Jared Parsons — Fri, 25 Apr 2008 18:09:08 GMT

Recently we had a good discussion on an internal alias about the use of Me, MyClass and MyBase in VB. Me, MyBase and MyClass are all ways to access instance member data in a VB class or structure. There was a little bit of confusion on the actual workings and meanings of the keywords in various contexts and I want to use this post to shed light on the different meanings.

The Basics

The keywords are used to alter the way in which instance members of a class/structure are accessed. In particular they affect the way Overridable/MustOverride/Overrides functions are evaluated. Methods defined with Overridable/Overrides/MustOverride are defined as virtual by the CLR. For the purpose of this post all of these definitions are mostly equal. This discussion will be useless without and example so here's the code to discuss.

Class GrandParent
    Public Overridable Sub Sub1()
        Console.WriteLine("GrandParent.Sub1")
    End Sub
End Class

Class Parent
    Inherits GrandParent
    Public Overrides Sub Sub1()
        Console.WriteLine("Parent.Sub1")
    End Sub
End Class

Class Child
    Inherits Parent
    Public Overrides Sub Sub1()
        Console.WriteLine("Child.Sub1")
    End Sub
End Class

In this case Sub1 is a virtual method and there are three instances of it (one per class). By default virtual methods are called based on the runtime type of the object. The CLR will essentially walk the hierarchy from current type to object looking for the first class which defines a particular method and call that version. It doesn't matter what the variable type is declared as, just what type it actually is.

Dim v1 As GrandParent = New Parent
v1.Sub1()   ' Calls Parent.Sub1
Dim v2 As GrandParent = New GrandParent
v2.Sub1()   ' Calls GrandParent.Sub1

Changing the call

If the CLR will always call a virtual Sub/Function based on the runtime type of an object how can I access the parent function? This is where MyBase comes in. MyBase allows you to call the version of the virtual method defined in the parent class. Essentially it tells the CLR call this method/property as if my runtime type was my base type.

Class Child2
    Inherits Parent
    Public Overrides Sub Sub1()
        MyBase.Sub1()   ' Calls Parent.Sub1
        Console.WriteLine("Child2.Sub1")
    End Sub
End Class

MyClass is similar to MyBase. Instead of telling the CLR the current type is the base type, it tells the CLR the runtime type is the type where MyClass is used. This allows developers to call their type's version of a virtual method no matter who derives from them. In the following example it doesn't matter how many, or who derives from Child3, Sub2 will always call the version of Sub1 defined in Child3.

Class Child3
    Inherits Parent
    Public Overrides Sub Sub1()
        Console.WriteLine("Child3.Sub1")
    End Sub
    Public Sub Sub2()
        MyClass.Sub1()
    End Sub
End Class

So, why not MyChild?

The short answer is, it's not verifiable. When writing MyBase we can verify that indeed there is a sub/function/property matching the call site in the base class. If no such method exists it will result in an error. MyClass is similarly easy to verify. With MyChild however there would be no useful way of guaranteeing a particular sub/function/property was defined on the child class.

One way you can verify a child class contains a particular property/sub/function is to make it MustOverride. However in this case there is no actual definition in the original type. In fact, if you try and access a MustOverride method with MyClass it will generate a compile time error. Therefore every call must at least occur in the child class or lower rendering MyChild superfluous.

What about non-virtual methods and properties?

The primary intent of MyBase/MyClass is to call virtual methods in a non-virtual way. However they can also be used to call non-virtual methods. From the perspective of the user calling a non-virtual method with MyBase/MyClass/Me has no discernable difference. If you crack open the generated IL you can see a small difference in the op code but the short story is it won't affect your program.

BinaryInsert Part2

Jared Parsons — Mon, 07 Apr 2008 22:09:36 GMT

Previously I discussed a potential missing API in List(Of T).BinaryInsert. One of the items I mentioned was it had better performance because it was O(Log N) vs Insert and Sort which is O(NLogN). Several users correctly pointed out this was incorrect and that Insert() had the additional overhead of an Array.Copy() which is O(N)ish. But most agreed O(N) + O(LogN) was better than O(NLogN).

Given that I already missed a key portion, I decided to write a test program to try out the various methods. Caveat: I'm not a performance guy. While I find performance intriguing and interesting it is by no means my specialty. Any single performance test is unlikely to capture all real world scenarios. However I did find the results a bit surprising. At the bottom of the post is the test code I wrote.

Here is the summary output.

Force Jit
BinaryInsert:     00:00:00.0051167
Insert Then Sort: 00:00:00.0000251
Range (0-99)
BinaryInsert:     00:00:00.0000266
Insert Then Sort: 00:00:00.0000316
Random 10
BinaryInsert:     00:00:00.0000053
Insert Then Sort: 00:00:00.0000034
Random 100
BinaryInsert:     00:00:00.0000294
Insert Then Sort: 00:00:00.0000235
Random 1000
BinaryInsert:     00:00:00.0004917
Insert Then Sort: 00:00:00.0001526
Random 10000
BinaryInsert:     00:00:00.0261899
Insert Then Sort: 00:00:00.0018287
Random 100000
BinaryInsert:     00:00:02.4289054
Insert Then Sort: 00:00:00.0237019

As you can see, based on my sample program, BinaryInsert is much slower than Insert and Sort. I ran the profiler against this and verified the suspicion that List(Of T).Insert() took the vast majority of the time.

Perhaps there is a reason BinaryInsert is missing.

Module Module1

    Function BinaryInsert(Of T)(ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T)) As TimeSpan
        Dim list As New List(Of T)
        Dim watch As New Stopwatch()

        watch.Start()
        For Each value In enumerable
            list.BinaryInsert(value, comp)
        Next
        watch.Stop()
        Return watch.Elapsed
    End Function

    Function InsertAllThenSort(Of T)(ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T)) As TimeSpan
        Dim list As New List(Of T)
        Dim watch As New Stopwatch()

        watch.Start()
        For Each value In enumerable
            list.Add(value)
        Next
        list.Sort(comp)
        watch.Stop()
        Return watch.Elapsed
    End Function

    Sub TestBoth(Of T)(ByVal title As String, ByVal enumerable As IEnumerable(Of T))
        TestBoth(title, enumerable, Comparer(Of T).Default)
    End Sub

    Sub TestBoth(Of T)(ByVal title As String, ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T))
        Dim copy = New List(Of T)(enumerable)
        Dim ellapsedBinary = BinaryInsert(New List(Of T)(copy), comp)
        Dim ellapsedSort = InsertAllThenSort(New List(Of T)(copy), comp)

        Console.WriteLine(title)
        Console.WriteLine("BinaryInsert:     {0}", ellapsedBinary)
        Console.WriteLine("Insert Then Sort: {0}", ellapsedSort)
    End Sub

    Function Range(ByVal start As Integer, ByVal count As Integer) As List(Of Integer)
        Dim list = New List(Of Integer)
        For i = start To count - 1
            list.Add(i)
        Next
        Return list
    End Function

    Function Random(ByVal count As Integer) As List(Of Integer)
        Dim rand As New Random()
        Dim list = New List(Of Integer)
        For i = 0 To count - 1
            list.Add(rand.Next())
        Next
        Return list
    End Function

    Sub Main()
        TestBoth("Force Jit", New Integer() {1})
        TestBoth("Range (0-99)", Range(0, 100))
        TestBoth("Random 10", Random(10))
        TestBoth("Random 100", Random(100))
        TestBoth("Random 1000", Random(1000))
        TestBoth("Random 10000", Random(10000))
        TestBoth("Random 100000", Random(100000))
    End Sub

End Module

Have a IComparable(Of T) but need an IComparer(Of T)?

Jared Parsons — Thu, 03 Apr 2008 04:33:52 GMT

IComparable(Of T) is an interface saying "I can compare myself to other objects of the same type". And IComparer(Of T) is an interface saying "I can compare two objects of this type.". Often API's which need to perform comparisons will take an instance of IComparer(Of T) instead of IComparable(Of T).

Doing the opposite is limiting in a few ways. The first is it locks developers into the behavior defined by the type author essentially preventing them from deciding to compare in a different way. The second is if the type author didn't didn't implement IComparable(Of T), we must define a wrapper class that does. This is even more awkward because collections now contain instances of the wrapper. Also there is one wrapper overhead per instance in the collection.

Now back to the original problem, we have a type which implements IComparable(Of T) but don't have an IComparer(Of T) wrapper class. Luckily the .Net Framework provides a solution. Comparer(Of T).Default. It provides a quick IComparer(Of T) wrapper that automatically delegates to IComparable(Of T) if the type defines it.

Example usage: Previously we defined a BinaryInsert method for List(Of T). It required an explicit IComparer(Of T) be passed even for simple types like Int32. We can fix this by using the Comparer(Of T) class.

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), ByVal value As T)
        list.BinaryInsert(value, Comparer(Of T).Default)
    End Sub

Missing API: List(Of T).BinaryInsert

Jared Parsons — Mon, 31 Mar 2008 17:26:42 GMT

One API that seems to be missing from List(Of T) is a BinaryInsert method. Especially since there is already a BinarySearch method.

Binary insert is a method for inserting a value into an already sorted list. Since the list is already sorted we can do a binary search to find the appropriate place to insert. The insert keeps the list sorted so the cost of a binary insert is just the cost of the search which is O(Log(N)).

An alternative method for keeping a sorted list sorted is to insert and then resort. Most sorting algorithms have a cost of O(N*Log(N)). In other words it's N times more expensive.

Yet this API doesn't exist. No matter. We can quickly fix this problem with a couple of extension methods.

Public Module Extensions

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), ByVal value As T, ByVal comp As IComparer(Of T))
        list.BinaryInsert(value, comp, 0, list.Count)
    End Sub

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), _
                                  ByVal value As T, _
                                  ByVal comparer As IComparer(Of T), _
                                  ByVal iStart As Integer, _
                                  ByVal iEnd As Integer)
        While iStart < iEnd
            Dim len = iEnd - iStart
            Dim iMiddle = iStart + (len \ 2)
            Dim comp = comparer.Compare(value, list(iMiddle))
            If 0 = comp Then
                iStart = iMiddle
                Exit While
            ElseIf comp < 0 Then
                iEnd = iMiddle
            Else
                iStart = iMiddle + (len Mod 2)
            End If
        End While
        list.Insert(iStart, value)
    End Sub

End Module