views:

1280

answers:

6

Due to a bug that was fixed in C# 4, the following program prints true. (Try it in LINQPad)

void Main() { new Derived(); }

class Base {
    public Base(Func<string> valueMaker) { Console.WriteLine(valueMaker()); }
}
class Derived : Base {
    string CheckNull() { return "Am I null? " + (this == null); }
    public Derived() : base(() => CheckNull()) { }
}

In VS2008 in Release mode, in throws an InvalidProgramException. (In Debug mode, it works fine)

In VS2010 Beta 2, it doesn't compile (I didn't try Beta 1); I learned that the hard way

Is there any other way to make this == null in pure C#?

+1  A: 

I could be wrong, but I'm pretty sure if your object is null there's never going to be a scenario where this applies.

For instance, how would you call CheckNull?

Derived derived = null;
Console.WriteLine(derived.CheckNull()); // this should throw a NullReferenceException
Dan Tao
In a lambda in the constructor argument. Read the entire code snippet. (And try it if you don't believe me)
SLaks
I agree although I do remember faintly something about how in C++ an object didn't have reference within it's constructor and I'm wondering if the (this == null) scenario is used in those cases to check whether a call to a method was made from the object's constructor before exposing a pointer to "this". Though, as far as I know in C#, there shouldn't be any cases where "this" would ever be null, not even in the Dispose or finalization methods.
jpierson
The null value is captured at the right moment.
Henk Holterman
I guess my point is that the very idea of `this` is mutually exclusive of the possibility of being null--sort of a "Cogito, ergo sum" of computer programming. Therefore your desire to use the expression `this == null` and ever have it return true strikes me as misguided.
Dan Tao
In other words: I did read your code; what I'm saying is that I question what you were trying to accomplish in the first place.
Dan Tao
This code simply demonstrates the bug, and, as you pointed out, is utterly useless. To see real useful code, read my second answer.
SLaks
A: 
leppie
How did you do it?
SLaks
Was late, was a sign I should stop coding :) Was hacking our with DLR stuff IIRC.
leppie
+9  A: 

The raw decompilation (Reflector with no optimizations) of the Debug mode binary is:

private class Derived : Program.Base
{
    // Methods
    public Derived()
    {
        base..ctor(new Func<string>(Program.Derived.<.ctor>b__0));
        return;
    }

    [CompilerGenerated]
    private static string <.ctor>b__0()
    {
        string CS$1$0000;
        CS$1$0000 = CS$1$0000.CheckNull();
    Label_0009:
        return CS$1$0000;
    }

    private string CheckNull()
    {
        string CS$1$0000;
        CS$1$0000 = "Am I null? " + ((bool) (this == null));
    Label_0017:
        return CS$1$0000;
    }
}

The CompilerGenerated method doesn't make sense; if you look at the IL (below), it's calling the method on a null string (!).

   .locals init (
        [0] string CS$1$0000)
    L_0000: ldloc.0 
    L_0001: call instance string CompilerBug.Program/Derived::CheckNull()
    L_0006: stloc.0 
    L_0007: br.s L_0009
    L_0009: ldloc.0 
    L_000a: ret

In Release mode, the local variable is optimized away, so it tries to push a non-existant variable on to the stack.

    L_0000: ldloc.0 
    L_0001: call instance string CompilerBug.Program/Derived::CheckNull()
    L_0006: ret

(Reflector crashes when turning it into C#)


EDIT: Does anyone (Eric Lippert?) know why the compiler emits the ldloc?

SLaks
+2  A: 

This isn't a "bug". This is you abusing the type system. You are never supposed to pass a reference to the current instance (this) to anyone within a constructor.

I could create a similar "bug" by calling a virtual method within the base class constructor as well.

Just because you can do something bad doesn't mean its a bug when you get bit by it.

Will
It is a compiler bug. It generates invalid IL. (Read my answer)
SLaks
The context is static, so you should not be allowed an instance method reference at that stage.
leppie
You do something you should never do, then shiz breaks. And that's a compiler bug? Again, there are things you can do that you aren't supposed to do which will break, it doesn't mean that it is a bug because the compiler couldn't handle your acting badly.
Will
Besides, `this` will never equal null. It doesn't make any goddamn sense. If you find yourself saying "Am I dead," you can relax because you're not. Because dead people *can't ask themselves anything*.
Will
@Will: That's what compiler errors are for.
SLaks
@Will: It's a compiler bug. The compiler is supposed to generate *valid*, *verifiable* code for that code snippet or spit out an error message. When a compiler does not behave according to the spec, **it is buggy**.
Mehrdad Afshari
The thing is if this is "fixed" in 4.0 then it is still broken, as `this` can never equal `null`. Maybe it has to do with their shoehorning in the DLR?
Will
I find it hard not to argue with someone who relies on "compiler bugs" for their code to work, forgive me.
Will
@Will: "The thing is if this is "fixed" in 4.0 then it is still broken, as `this` can never equal `null`." Isn't it how it should be? Do you ever check `if (this != null)` in instance methods? C# programmers rely on `this` not being `null`. The old behavior did not implement the spec correctly.
Mehrdad Afshari
@Will#4: When I wrote the code, I hadn't thought about the implications. I only realized that it didn't make sense when it stopped compiling in VS2010. –
SLaks
@Will#3: What on earth do you mean?
SLaks
By the way, the virtual method call in constructor is a completely valid operation. It's just not recommended. It *may* result in logical disasters but never an `InvalidProgramException`.
Mehrdad Afshari
I try to stay away from valid operations that can result in logical disasters, heheh.
Will
@will looks like u got owned here
i am a girl
+8  A: 

This observation has been posted on StackOverflow in another question earlier today.

Marc's great answer to that question indicates that according to the spec (section 7.5.7), you shouldn't be able to access this in that context and the ability to do so in C# 3.0 compiler is a bug. C# 4.0 compiler is behaving correctly according to the spec (even in Beta 1, this is a compile time error):

§ 7.5.7 This access

A this-access consists of the reserved word this.

this-access:

this

A this-access is permitted only in the block of an instance constructor, an instance method, or an instance accessor.

Mehrdad Afshari
A: 

Not sure if this is what you are looking for

    public static T CheckForNull<T>(object primary, T Default)
    {
        try
        {
            if (primary != null && !(primary is DBNull))
                return (T)Convert.ChangeType(primary, typeof(T));
            else if (Default.GetType() == typeof(T))
                return Default;
        }
        catch (Exception e)
        {
            throw new Exception("C:CFN.1 - " + e.Message + "Unexpected object type of " + primary.GetType().ToString() + " instead of " + typeof(T).ToString());
        }
        return default(T);
    }

example: UserID = CheckForNull(Request.QueryString["UserID"], 147);

Scott and the Dev Team
You _completely_ misunderstood the question.
SLaks
I figured as much. Thought I'd try anyway.
Scott and the Dev Team