Calculate return value for sort by int

Most programming languages (such as C#, Java, …) allow you to sort lists. Most of them also allow you to specify a sorting function so that you can customize the sort order. These functions usually take parameters a and b and define the return value as follows:

Return value if
less than zero a is less than b
equals zero a is equal to b
greater than zero a is greater than b

Usually you would do something like this (code in C#):

int Compare(int a, int b) {
  if (a < b) {
    return -1;
  }
  else if (a > b) {
    return 1;
  }
  else {
    return 0;
  }
}

However, when comparing int values, there’s a much quicker way to do this:

int Compare(int a, int b) {
  return a - b;
}

That’s it.

Note: Care should be taken if a and/or b can come close to int.MaxValue or int.MinValue. In this case the results may not be what one wants (like if a = int.MinValue and b = 1 then the result will be int.MaxValue which is wrong obviously).

Bug of the day: Broken renaming in ReSharper

In my opinion, refactoring is the way to keep a software project clean. So, it’s good to have tools that support the refactoring process.

ReSharper is such a tool. It provides refactoring capabilities for C#/Visual Studio.

Unfortunately, the renaming code in ReSharper currently (version 7.1.1) contains a bug. This bug may prevent ReSharper from renaming all occurrences of a certain symbol.

The following code exhibits this problem:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using System;
 
public class SomeOtherClass {
  public string GetString(int col) {
    return null;
  }
}
 
public class MyClass {
  public void YouCantRenameMe() { }
 
  public void ThisFunctionBreaksTheRenaming() {
    // The following line breaks the renaming.
    SomeFunction((row) => row.GetString(0));
  }
 
  public void SomeFunction<T>(Func<SomeOtherClass, T> func) {
    YouCantRenameMe();
  }
}

If you try to rename the method YouCantRenameMe() (in line 10), ReSharper won’t rename the method call in line 18.

The problem is the code in method ThisFunctionBreaksTheRenaming() which somehow breaks the renaming process.

Update: This bug is not present in version 7.1. So, for now, I’ve downgraded to this version.

WCF: Real Easy

If you search for WCF tutorials, you’ll find a lot of elaborate examples that involve editing several files.

This tutorial is (supposed to be) different. It uses the simple most approach I could find for using WCF. It’ll only involve one file and no XML descriptors (read: app.config).

I’ll explain how to use WCF for communicating between .NET processes and how to use it for HTTP requests.

The initial code is based primarily on this nice tutorial.

Let’s get started.

Read more →

C++/CLI Cheat Sheet

This article provides a quick comparison between C++/CLI and C#. It’s meant for those who know C# (and possibly C++) and will explain which C++/CLI language construct correspond with which in C#. (I don’t know Visual Basic so I can’t add infos about this here.)

Note: This is not a complete reference but rather quick reference for those features that are (in my opinion) the most unclear.

Read more →

C# and GC.KeepAlive()

Today, while browsing some C++/CLI code, I stumbled upon several calls to GC.KeepAlive(someObj).

Immediately I thought memory leak – because I thought KeepAlive() would keep the object alive indefinitely.

Fortunately, this turned out to be wrong, though.

After reading the documentation of GC.KeepAlive() (couldn’t really figure it out), I did some decompiling and found out that GC.KeepAlive() looks like this:

1
2
3
4
[MethodImpl(MethodImplOptions.NoInlining)]
public static void KeepAlive(object obj)
{
}

It just does nothing. So what’s its purpose?

It’s there to fake an access to a variable.

Why? The .NET garbage collector may collect a variable directly after its last use – and not necessarily, contrary to common belief, at the end of the variable’s scope.

Consider this code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class SomeClass
{
  // This field is initialized somewhere 
  // in the constructor (not shown here).
  public SomeOtherClass Value;
 
  ...
}
 
...
 
void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  YetAnotherMethod();
  // obj still alive here? Possibly not.
}

The garbage collector may collect obj just after the runtime has retrieved obj.Value (line 15), i.e. before SomeOtherMethod() is even called.

Note: The exact line where obj will be marked for collection is up to the JIT compiler. The behavior describe above seems to be called “lookahead optimization”.

Usually this optimization not a problem. It becomes a problem, however, if SomeClass has a finalizer:

1
2
3
4
5
6
7
8
9
10
11
class SomeClass
{
  public SomeOtherClass Value;
 
  ~SomeClass()
  {
     // "Value" can't be used anymore 
     // after Dispose() has been called.
     this.Value.Dispose();
  }
}

So, if obj‘s finalizer is executed before SomeOtherMethod() is called, SomeOtherMethod() won’t be able to use obj.Value anymore.

To solve this problem, add GC.KeepAlive() after the call to SomeOtherMethod(), like this (line 5):

1
2
3
4
5
6
7
void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  GC.KeepAlive(obj);
  YetAnotherMethod();
}

This way, the garbage collector won’t collect obj (and thus run its finalizer) before line 5 has been reached.

Notes:

  • The implementation of the finalizer of SomeClass is flawed – as the examples in this article show. The user shouldn’t need to worry about Value being disposed too early.

    • Rule of thumb: A finalizer should only dispose the resources of its own class, not resources of some member (by calling Dispose() on members).
    • The problem with the finalizer persists if Value is an unmanaged resource/pointer that’s being passed to SomeOtherMethod(). This is always possible in C++/CLI. In C# Value could be of type IntPtr.
    • In the examples above, consider implementing and using IDisposable for SomeClass instead of GC.KeepAlive(), if you need a finalizer.
    • You still need to use GC.KeepAlive() if you can’t change the implementation of SomeClass.
  • Using GC.KeepAlive() is like using GCHandle, just more light-weight and faster.
  • GC.KeepAlive() only works because it can’t be inlined by the compiler (MethodImplOptions.NoInlining).