Differences between vb.net and c#

adgonz

Do you think this two pieces of code are the same? C#

    private string f()
    {
        System.Nullable<System.Int32> a = null;
        System.Nullable<System.Int32> b = 7;
        if (a != b)
        {
            return "apple";
        }
        else
        {
            return "orange";
        }
    }

vb.net

Function f() As String
    Dim a As System.Nullable(Of System.Int32) = Nothing
    Dim b As System.Nullable(Of System.Int32) = 7
    If a <> b Then
        Return "apple"
    Else
        Return "orange"
    End If
End Function

Luc Pattyn

I did. But no longer. Right now I would say VB.NET has a bug. I opened the EXE with Reflector and did not like what I saw. Comparing two nullables fails as soon as one or both are Nothing. [ADDED] I investigated a bit further and wrote this little article[^] about it. [/ADDED] :)

Luc Pattyn

Local announcement (Antwerp region): Lange Wapper? Neen!

modified on Thursday, February 24, 2011 4:10 PM

Chris Meech

Logically they are the same. But comparison operators with NULL parameters are notoriously inconsistent which is why whenever you are comparing a couple of fruits, make sure that both of them are non-null before you compare them. :)

Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]

cjb110

does the situation change if both comparisons are != or <>?

adgonz

cjb110 wrote:

does the situation change if both comparisons are != or <>?

Sorry, don't understand your question. Can you explain?

cjb110

Well the vb example has 'if a<>b' but the c# has 'if a!=b'. I was just thinking that you can't say if nothing/null is < 7 or if its > 7, but you could say nothing/null is not equal 7. But I don't use vb.net, so I don't know if its defined that the <> operator is the same as the != operator.

adgonz

The thing is that vb.net evaluates the comparison to Nothing when one of the operands is Nothing. And something like:

If Nothing Then

End If

Is valid, even if you specify Option Strict On

adgonz

<> is (I used to think it was) to vb.net the same as != to C#

Ian Shlasko

Yep... VB doesn't have the != operator. It uses <> for inequality.

Proud to have finally moved to the A-Ark. Which one are you in? Developer, Author (Guardians of Xen)

PIEBALDconsult

!= == <> ?

Luc Pattyn

only for non-nullables apparently. :omg:

Luc Pattyn

Local announcement (Antwerp region): Lange Wapper? Neen!

Henry Minute

Very interesting. Have you told Microsoft about this, or do you think that they already know? More interestingly, what do you think would break, if they fixed it?:~

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

adgonz

Question:

PIEBALDconsult wrote:

!= == <> ?

Answer: != == Not Nullable.Equals(,)

Gideon Engelberth

I would have assumed so, but apparently the C# and VB compilers have different rules for how they generate the extra code to pretend that Nullable(Of T) has equality and inequality operators for at least the numeric types (It could be for all types that have the equality and inequality operators; I did not check). VB seems to say that Nothing is neither equal nor inequal to non-Nothing. C# on the other hand, compares "ValueOrDefault" first. If both are the same, it will check if both are either null or non-null. Since this is done by the compilers, I am not particularly surprised that they are different, though it would have been nice to be the same. At this point though, changing one or the other could cause subtle bugs in working programs.

Michael Eber

Knowing my experience in the past working with the VB.NET developer team, they would all whine that you just "didn't get it" and they do not have a bug. That everything works fine and it's C# that is buggy. ;)

Michael Eber

That is very very true. Try creating an object within a method, and within an if statement and then a for loop try accessing that object. (I believe that is the correct sequence but it was a while ago that I ran into this) In VB.NET that compiles down to a late bind in the IL which will add hidden overhead.

Steven J Jowett

adgonz wrote:

Do you think this two pieces of code are the same?

Well, errm, No. One is C# and the other is VB.NET. Don't you just hate a smart-ar$e ;)

Steve Jowett ------------------------- Real programmers don't comment their code. If it was hard to write, it should be hard to read.

peterchen

:D Still you shoul report it to MS Connect, just as your civic duty. (You could also post it for the C# guys to give them more neener ammo against the Veebees)

Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch

Michael Dunn

I bet Eric Lippert[^] would be interested in hearing (and possibly writing) about this.

--Mike-- Dunder-Mifflin, this is Pam.

dojohansen · modified on Thursday, February 24, 2011 4:10 PM

Luc Pattyn wrote:

I opened the EXE with Reflector and did not like what I saw. Comparing two nullables fails as soon as one or both are Nothing.

How do you know that? If you look at the method it's fairly clear that it's possible to optimize the method to the equivalent of

string f() { return "apple"; }

since the local variables are never modified. I don't know if the compiler optimization goes this far, but if judging this based on the IL output optimization certainly must be taken into account.

Luc Pattyn wrote:

Right now I would say VB.NET has a bug.

I haven't tried to run the code, but I have a hard time believing VB.NET could have such a fundamental bug after years of use. My guess is VB.NET defines the equals and not equals operators differently from C# when one or more of the operands is null. T-SQL too has superficially weird handling of null operands with these operators, although there is a good reason in this case (when people implement inner joins in the WHERE clause and one or both columns is nullable). Try this T-SQL for example:

declare @b char(2);
set @b = null;
IF @b = null PRINT '@b = null? YES' ELSE PRINT '@b = null? NO';
IF @b <> null PRINT '@b <> null? YES' ELSE PRINT '@b <> null? NO';