First off, let's consider just straight up concatenation of string variables; in fact, let's assume that all variables are strings for the purposes of this article. If you have:

r = a + b;

then clearly that is going to be generated as

r = String.Concat(a, b);

But what about

r = a + b + c;

? String addition, like all addition in C#, is left associative, so this is the same as

r = (a + b) + c;

So you might think that would be generated as

r = String.Concat(String.Concat(a, b), c);

but the compiler can be more efficient than that because there is an overload of String.Concat which takes three operands and produces the same result:

r = String.Concat(a, b, c);

Ditto for four operands. However when we get to five or more operands the compiler switches to a different overload:

r = a + b + c + d + e;

is generated as

r = String.Concat(new String[5] { a, b, c, d, e });

It's a bit unfortunate that you have to take on the cost of allocating an array, but there it is.

That's all very straightforward, but there are more optimizations that the C# compiler performs. The main optimization depends upon the fact that string concatenation is fully associative.² That is, the parentheses don't matter. You might think that an oddity like

r = a + (b + c);

would have to be generated as

r = String.Concat(a, String.Concat(b, c));

but of course we can observe that since string concatenation is associative, this is no different than

r = (a + b) + c;

which we already know how to generate efficiently. The C# compiler's string optimizer automatically rewrites nested string concatenations into the left-parenthesized form no matter how you parenthesize them. Except when it doesn't, which is our next optimization. Let's now consider the impact of constants:

r = "A" + "B" + c;

The compiler will parse this as:

r = ("A" + "B") + c;

and of course that first term is a compile-time constant according to the spec. The compiler automatically computes values of compile-time constants, so this is the same as:

r = String.Concat("AB", c);

But what about this?

r = a + "B" + "C";

There are two compile-time constants, but this is parsed as

r = (a + "B") + "C";

Since both addition operators have a non-constant element on their left side, you might think this would have to be generated as

r = String.Concat(a, "B", "C");

But again associativity comes to the rescue. The optimizer notices that the original expression is the same as

r = a + ("B" + "C");

and generates

r = String.Concat(a, "BC");

And it will even do the right consolidation of constants "in the middle":

r = a + "B" + "C" + d;

is generated as though you'd said:

r = (a + ("B" + "C")) + d;

to produce

r = String.Concat(a, "BC", d);

The C# compiler also knows that empty string constants are the identity elements of concatenation; they are eliminated. If you say

r = a + "" + b;

Then the code generated is not

r = String.Concat(a, "", b);

but rather simply

r = String.Concat(a, b);

Null string constants are likewise identity elements:

const string NullString = null;
r = a + NullString + b;

is similarly generated as

r = String.Concat(a, b);

OK I must admit I just made a bald-faced lie there; did you catch it?

The null and empty strings are not identities of concatenation. An identity of an operator has the property that it leaves the other operand unchanged; zero is the identity of addition of numbers because any number plus zero gives you the original number. But there is one possible operand that is not preserved by addition with an empty or null string: the null string! NullString + NullString and NullString + "" both result in the empty string, not the null string, so neither is an identity.

You might think then that

r = a + NullString;

must be generated as

r = String.Concat(a, NullString);

because the compiler needs to ensure that if a is null then the result is the empty string. In fact the C# compiler anticipates what String.Concat will do and simply inlines it. This is generated the same as:

r = a ?? "";

which I think is a neat trick, to elide the concatenation entirely.

Next time on FAIC: An optimization the C# compiler does not perform.

In a nutshell, the difference is: the sizeof operator takes a type name and tells you how many bytes of managed memory need to be allocated for an instance of that struct.¹ By contrast, Marshal.SizeOf takes either a type object or an instance of the type, and tells you how many bytes of unmanaged memory need to be allocated. These can be different for a variety of reasons. The name of the type gives you a clue: Marshal.SizeOf is intended to be used when marshaling a structure to unmanaged memory.

Another difference between the two is that the sizeof operator can only take the name of an unmanaged type; that is, a struct type whose fields are only integral types, Booleans, pointers and so on. (See the specification for an exact definition.) Marshal.SizeOf by contrast can take any class or struct type.

class Foo 
{ 
    private int x;
    private int y;
    public Foo(int x, int y) 
    {
        this.x = x;
        this.y = y;
        SideEffects.Alpha(); // Notice: does not use "this"
    }
    ~Foo() 
    { 
        SideEffects.Charlie(); 
    }
}
static class SideEffects
{
    public static void Alpha() { ... }
    public static void Bravo() { ... }
    public static void Charlie() { ... }
    public static void M()
    {
        Foo foo = new Foo(1, 2); 
        Bravo();
    }
}

Let's suppose we have three side effects: Alpha, Bravo and Charlie. What precisely they are is not important.

The question is: what do we know about the order in which Alpha, Bravo and Charlie execute when a call to M() occurs?

First off, clearly Alpha must happen before Bravo. The C# compiler and the jit compiler are not permitted to make any optimization that would cause the side effects of a single-threaded program to appear out of order. The construction of foo must be complete before control is passed to Bravo, which means that Alpha has already run.

You might think that Charlie has to happen after Bravo by the following reasoning: Charlie does not run until the object referred to by foo is garbage collected. The local foo is alive until the end of M and therefore it cannot be collected until after Bravo.

This reasoning is incorrect. The C# compiler and the jitter are both permitted to notice that foo is never read from after its initial write, and therefore it can be garbage collected before the end of M, and therefore can be garbage collected before Bravo.

But didn't I just say that the compilers were not permitted to make this optimization? No, I did not. I said that they were not permitted to make this optimization in a single-threaded program, but the garbage collector and the finalizer queue run on their own threads! The C# language makes very few guarantees about how side effects are ordered in a multi-threaded program; only very special side effects like volatile writes, thread creation, and so on, are guaranteed to be observed in a particular order.

So it is legal for Charlie to happen before -- or during! -- Bravo. But surely¹ Charlie happens after Alpha?

Nope! This isn't guaranteed either. The jitter can notice that foo is never read from and is therefore useless; it can throw it away entirely. The jitter can then notice that neither the reference to this nor fields x and y are ever used after this.y = y;, and mark the object as a candidate for finalization before Alpha. It is possible for an object to be destructed while its constructor is running on another thread!

This is of course extremely unlikely, but it is legal, and therefore you have to assume the worst. This is yet another reason why it is so difficult to write a correct destructor in .NET; you can't assume that the constructor finished before the destructor runs, so any invariants that you're setting up in your constructor are not necessarily valid in the destructor.

So what do you do if you're in this crazy situation and you require Charlie to run after Bravo?

    public static void M()
    {
        Foo foo = new Foo(1, 2); 
        Bravo();
        GC.KeepAlive(foo);
    }

The GC.KeepAlive method is a very special method that tells the jitter and the garbage collector that the lifetime of foo must be extended to at least this point. Make sure you understand that: when you call KeepAlive, the object is alive before the call and possibly dead after the call.

Of course, the far better thing to do would be to make Foo expose its cleanup² and simply say:

    public static void M()
    {
        Foo foo = new Foo(1, 2);
        Bravo();
        foo.Close();
    }

and then have Charlie run in the Close. Now we're on one thread again and the side effects must be correctly ordered. If the order of the calls is important for the correct functioning of the program then let's write a program that obviously calls them in the right order.

In general, no, because of overflow. In a checked context the right side can overflow and produce an exception but the left side cannot. In an unchecked context two large positive values for b and c can overflow to a negative number on the right hand side, thereby producing a different result than the left hand side.

Moreover, commenter "Peter" points out that if b is -1 then (a/b) can overflow too; I hadn't thought about that case, so good catch.

But what about the specific case where a, b, and c are positive numbers and there are no overflows in either expression? Can we rely on this identity under those circumstances?

Let's find out!

We begin by going back to the definition of integer division; as I've described before, there are two operators: the division operator and the remainder operator. Suppose we have (again supposing that x and y are positive integers):

r = x % y
q = x / y

The relationship between those values is:

x = q * y + r

where 0 <= r < y

Let's break our suspected identity apart into left and right sides. Let's say that the first division on the left side is:

qab = a / b
rab = a % b
b * qab + rab = a
0 <= rab < b

So our left hand side is qab / c. The quotient and remainder of that are:

qleft = qab / c
rleft = qab % c
c * qleft + rleft = qab
0 <= rleft < c

We can eliminate qab through substitution to get the equation:

b * c * qleft + b * rleft + rab = a

OK, that will do for the left hand side. For the right hand side we have just one division:

qright = a / (b * c)
rright = a % (b * c)
b * c * qright + rright = a
0 <= rright < b * c

We now have two equations that equal the same thing, a, so let's set them equal to each other:

b * c * qleft + b * rleft + rab = b * c * qright + rright

We know that qleft and qright are both integers. Therefore there is an integer d, their difference, such that qleft + d = qright. Let's eliminate qright from our equation:

b * c * qleft + b * rleft + rab = b * c * qleft + b * c * d + rright

And solve for d:

d = (b * rleft + rab - rright) / (b * c)

d is an integer. Is possibly positive? Let's make some inequalities. We know that rright is non-negative, so the numerator of that fraction:

b * rleft + rab - rright <= b * rleft + rab

We know that rleft < c and c > 0 so

b * rleft + rab <= b * (c - 1) + rab

We know that rab < b, so:

b * (c - 1) + rab < b * (c - 1) + b

But that's b * c. Therefore the numerator of this fraction is strictly less than its denominator, and therefore the fraction must be strictly less than one. Since the fraction is an integer, d must be zero or negative; it cannot be positive.

The proof that d also cannot be negative and therefore must be zero is similar and is left as an exercise.

Since d is zero, qleft = qright, which establishes the identity -- again, provided that all the operands are positive numbers and the multiplication does not overflow.

Proving that the identity works for negative a, b and c is also left as an exercise.

I've noticed that the is operator is inconsistent in C#. Check this out:

string s = null; // Clearly null is a legal value of type string
bool b = s is string; // But b is false!

What's up with that?

Let's suppose you and I are neighbours.

Um... ok, I'm not sure where this is going, but sure.

I'm looking into your driveway, which is empty. Can that driveway hold a Honda Civic?

Sure, no problem. In fact, it frequently does.

Now we cross the street and we look at my driveway, which is also empty. Can it hold a Honda Civic?

Yes, I suppose so.

In fact I have a rule that only Honda Civics may be parked in my driveway.

That's a bit weird, but that's your business.

Can the present contents of my driveway be placed in your driveway?

Um... I don't know. That's a strange question. On the one hand I want to say that the question presupposes a false premise, namely that "the present contents of my empty driveway" refers to an object that can be moved from one place to another. On the other hand, the contents of our two empty driveways seem to be by definition "the same", namely, "zero Honda Civics". If you insist on an answer then I suppose I will have to say yes, the present contents of your driveway fit into my driveway.

OK, so, does your driveway contain a Honda Civic?

Obviously not. It's empty.

Well, aren't you being inconsistent then? Let's review the facts.

• You agree that my driveway only contains Honda Civics.
• You agree that the present contents of my driveway are identical to the contents of your driveway.
• And yet you conclude that your driveway does not contain a Honda Civic!

Either you are being inconsistent or there is something wrong with this logic.

I'd agree with that! There's something wrong with your logic.

And now we see why the is operator is actually consistent. The fact that a null reference may be assigned to a string variable does not make the null reference a string, any more than the fact that your driveway can be empty means that an empty driveway contains a Honda Civic. The is operator does not answer the question "can I assign this reference to a variable of the given type?" It answers the question "is this reference a legitimate reference to an object of the given type?", and null is not a legitimate reference.

I'm beginning to see your point, but actually I never believed that the operator was answering a question about assignment compatibility. I believed that the operator was answering a question about type membership. Surely the null reference is a member of the string type!

Someone once told me that the fastest way to spot the weak point in an argument is to look for the "surely".

Actually, no. A common conception of types is that a type is a set, possibly infinite, of values, and that assignment compatibility is merely checking to see if a given value is a member of the necessary set. But that's not the case in C#. The null reference actually is not assigned any type at all; it is explicitly of no type, but it is assignment compatible with a variable of any reference type.¹ The assignment compatibility relationship and the type membership relationship are similar in a lot of ways but they are not identical.

Finally I know what the true meaning of what is is!

Awesome! Alert Bill Clinton!

Next time on FAIC: An interesting integer identity.

Unsurprisingly, it's a private joke.¹ When I was first an intern at Microsoft almost twenty years ago now I decided to be brave and go explore downtown Seattle.² I got on the entirely wrong bus and ended up at some park-and-ride in the north end of the Eastside, which is the middle of a nigh endless suburbia, and did not realize my mistake until it was too late to do anything about it. It was just me and a very drunk man on the bus who kept telling me that I looked Australian. It took quite some doing to get back home again. I wrote this whole ridiculous story up in an email to my friends and family back home which I titled "FABULOUS ADVENTURES IN REDMOND". I sent home a number of FABULOUS ADVENTURES missives that winter and it got to be an inside joke. So naturally when I started a blog, the best possible title was immediately obvious to me.

So there you go. Not much of a secret science fiction origin story, really.

Next time on FAIC: I'm taking Memorial Day off; on Thursday we'll finally answer the age old question of what the meaning of the word "is" is.

namespace Alpha
{
    public class Bravo
    {
        public void Charlie()
        {
            System.Console.WriteLine("Alpha Bravo Charlie");
        }
    }
}

Pretty straightforward. You call this method from assembly Delta.EXE like this:

namespace Delta
{
    public interface IFoxtrot
    {
        void Charlie();
    }
    public class Echo : Alpha.Bravo, IFoxtrot
    {
    }
    public class Program
    {
        static void Main()
        {
            IFoxtrot foxtrot = new Echo();
            foxtrot.Charlie();
        }
    }
}

Notice that class Echo does not re-implement Charlie, but that's fine; the base class implementation suffices to meet the requirements of interface IFoxtrot. If we run this code and put a breakpoint on Charlie the call stack window in Visual Studio says:

Alpha.dll!Alpha.Bravo.Charlie()
[External Code]	
Delta.exe!Delta.Program.Main()
[External Code]	

It's unsurprising that there is "external code" inserted that calls Main for you, but what's with the "external code" between Main and Charlie? That should just be a straight call, right? Something strange is going on here.

It is possible for debugging purposes to programmatically inspect the call stack¹ so let's change the implementation of Charlie to print out the caller. This let's us do a bit of an end-run around the debugger² to see what is really happening there:

public void Charlie()
{
    System.Console.WriteLine("Alpha Bravo Charlie");
    System.Console.WriteLine((new System.Diagnostics.StackFrame(1).GetMethod().Name));
}

And now if we run it we get the output

Alpha Bravo Charlie
Delta.IFoxtrot.Charlie

What the heck is going on here?

What's going on is: the CLR requires that any method which implements an interface method be a virtual method, but the only candidate, Alpha.Bravo.Charlie, is non-virtual. Therefore when generating class Echo, the C# compiler actually generates the code as though you'd written:

    public class Echo : Alpha.Bravo, IFoxtrot
    {
        void Delta.IFoxtrot.Charlie()
        {
            base.Charlie();
        }
    }

The explicit interface implementation is a virtual method, satisfying the CLR. The compiler-generated method is marked as not having any source code, so the debugger writes External code in the call stack.

Mystery solved!

Extra credit mystery: Why did I have to specify that Echo and Bravo be in different assemblies? Leave your guesses in the comments.

Special thanks to Stack Overflow users Timwi and Jeff Moser for the inspiration for this blog post.

Next time on FAIC: Just why are these adventures so fabulous anyway?

I'll remind you all again that in C# the term "scope" has a very carefully defined meaning: the scope of a named entity is the region of program text in which the unqualified name can be used to refer to the entity.¹

For example, the scope of a local variable is the text of the block which declares it. The scope of a private method is the text of the body of the class or struct which declares it. And so on; the C# specification has careful definitions which define the scope of everything that has a name.

The word "lexical" means, in a broad sense "relating to text", and clearly we have defined "scope" as being a relationship involving text, so is this kind of scoping also called "lexical scoping"?

Sort of, but not exactly. Let me explain.

Programming languages can be broadly divided into two categories: the lexically scoped languages and the dynamically scoped languages. The difference between the two is: in a lexically scoped language, the meaning of an unqualified name can be completely determined by looking at the program text; the analysis can be done "statically". In a dynamically scoped language the meaning of an unqualified name can change at runtime; the name analysis can only be done "dynamically".

Let me give you an example; it is easiest to show this with lambdas.

class C
{
  public static Func<int> M()
  {
    int x = 123;
    return () => x;
  }
}
class P
{
  static void Main()
  {
    int x = 456;
    Func<int> f = C.M();
    System.Console.WriteLine(f());
  }
}

The question is: what gets printed out? C# is a lexically scoped language, so the meaning of x in the lambda is determined at compile time, by analyzing the text where the lambda was written. C# prints out 123. If C# were a dynamically scoped language then the meaning of x would be determined by analyzing the location where the delegate was executed at runtime, so it would print out 456.

Dynamically scoped languages essentially make the C# definition of scope useless; any method that executes a lambda in a dynamically scoped language makes the region of program text in which its locals can be referred to by their names arbitrarily large.

JavaScript, though a very dynamic language, is actually for the most part lexically scoped:

function M()
{
  var x = 123;
  return function () { return x; };
}
function N()
{
  var x = 456;
  var f = M();
  print(f()); // 123
}

However, JavaScript does have one feature which makes it dynamically scoped:

function Q(y)
{
  var x = 123;
  with(y)
    return x;
}
print(Q({ x : 456 })); // 456
print(Q(789));         // 123

Here the meaning of unqualified name x changes at runtime depending on whether y has a member x or not. For this reason I recommend avoiding the with block in JavaScript; it makes it hard for the reader to understand the meaning of the program.

Most modern languages are lexically scoped; experience has shown that lexical scoping is easier on all concerned; developers and maintenance programmers have an easier time understanding lexically scoped languages, and compiler developers have an easier time writing efficient compilers. Some variants of Lisp use dynamic scoping, though Scheme requires lexical scoping. There are still a few dynamically scoped languages in common usage though; PostScript, the programming language which runs on printers, is perhaps the most commonly used of them.

Next time on FAIC: We solve the mystery of the inserted method.

How bad does your quality assurance have to be to ship to customers a power supply that cannot possibly fit into a power socket?