zero-length string == nothing ??

Is this supposed to evaluate to TRUE in vb.net?
--------------------
Dim strMessage as String

If strMessage = "" Then
    'if true, do some stuff here
End If
-------------------

strMessage, in debug mode, shows a value of "Nothing".
Is "Nothing" supposed to equal a string of zero length?
I would have thought Nothing == Null.....which is different than ""

VB will use its own library to do string comparisons, of which is will essentially say that, null is nothing, zero length is nothing. If you pull the IL apart, you'll find VB calling a visual basic compiler services method of some sort.

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

stevo_ said:

VB will use its own library to do string comparisons, of which is will essentially say that, null is nothing, zero length is nothing. If you pull the IL apart, you'll find VB calling a visual basic compiler services method of some sort.

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

Under C# this would definitely not be the case - (String.Empty != null). There is a static method on the string class that provides simmilar functionality:

static bool String.IsNullOrEmpty(String str);

evildictaitor said:

stevo_ said:

*snip*

Under C# this would definitely not be the case - (String.Empty != null). There is a static method on the string class that provides simmilar functionality:

static bool String.IsNullOrEmpty(String str);

I appreciate the addition, but that really makes me sound like I've been doing .NET for 3 days or something

stevo_ said:

VB will use its own library to do string comparisons, of which is will essentially say that, null is nothing, zero length is nothing. If you pull the IL apart, you'll find VB calling a visual basic compiler services method of some sort.

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

Option Strict On ?

stevo_ said:

evildictaitor said:

*snip*

I appreciate the addition, but that really makes me sound like I've been doing .NET for 3 days or something

Anything you read into my comment further than the strictly technical details I provided was entirely unintentional.

ZippyV said:

stevo_ said:

*snip*

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

Option Strict On ?

No, its runtime agility:

http://community.bartdesmet.net/blogs/bart/archive/2007/09/03/visual-basic-9-0-feature-focus-runtime-agility.aspx

But its more if you drastically need compilation control I guess.. plus- it doesn't stop vb from trying to call that method.. but it does mean you get to define the method yourself.

stevo_ said:

ZippyV said:

*snip*

No, its runtime agility:

http://community.bartdesmet.net/blogs/bart/archive/2007/09/03/visual-basic-9-0-feature-focus-runtime-agility.aspx

But its more if you drastically need compilation control I guess.. plus- it doesn't stop vb from trying to call that method.. but it does mean you get to define the method yourself.

I'm slowly making the transition to C# and instances of code like this in our projects re-inforce that decision.

littleguru said:

You could probably use:

String.Compare(strMessage, "")

to walk around the "problem" of VB.NET. This will fall back to the bahaviour that you expect.

At least in VB6 "" a.k.a. vbNullString <> Nothing, so I doubt they'd change it VB.NET.  In fact I think it would give a compiler error in VB6, since a String isn't an object and only objects can be compared with Nothing.

I just tried this in VS2008 and it does evaluate to true....wow...does 0 equal nothing too, since that's the default value of an Integer....wow that does too....who made that decision?

ZippyV said:

stevo_ said:

*snip*

Kinda one of the reasons I don't like VB, brings a ton of crap with it (althought I think I heard you can tell the compiler not to do this now).

Option Strict On ?

Option Strict has no bearing on the problem.

And yes, VB considers Nothing and "" to be equivalent in string comparisons. It has done so since the first version of VB.NET (can't remember how VB6 behaved). I find it a very useful behaviour as writing foo = "" is easier than String.IsNullOrEmpty(foo), which has the same effect.

If you must make the distinction, use String.Compare as Littleguru suggested.

Sven Groot said:

ZippyV said:

*snip*

Option Strict has no bearing on the problem.

And yes, VB considers Nothing and "" to be equivalent in string comparisons. It has done so since the first version of VB.NET (can't remember how VB6 behaved). I find it a very useful behaviour as writing foo = "" is easier than String.IsNullOrEmpty(foo), which has the same effect.

If you must make the distinction, use String.Compare as Littleguru suggested.

Here I thought it might built-in with most apps in VS, by having the Microsoft.VisualBasic reference automatically added.
No such luck. It's default behavior like most here suggested.

My practice is to declare a string with a default value of either String.Empty or just plain "".
In this case, I either forgot or someone else forgot to do this.

Good point on String.Compare

strMessage Is String.Empty also works.

Well, in VB.NET Nothing has a very different meaning than Null in C#.  In C#, null refers only to reference types and means there is no reference assigned to the reference variable.  Nothing, on the other hand is the default value of any particular data type or object.

Sven Groot said:

ZippyV said:

*snip*

Option Strict has no bearing on the problem.

And yes, VB considers Nothing and "" to be equivalent in string comparisons. It has done so since the first version of VB.NET (can't remember how VB6 behaved). I find it a very useful behaviour as writing foo = "" is easier than String.IsNullOrEmpty(foo), which has the same effect.

If you must make the distinction, use String.Compare as Littleguru suggested.

Note that  String.IsNullOrEmpty is much faster then == "". If your in a loop (for example, when parsing a file) you can defiantly see the difference.

See: http://msdn.microsoft.com/en-us/ms182279.aspx

Programous said:

Sven Groot said:

*snip*

Note that  String.IsNullOrEmpty is much faster then == "". If your in a loop (for example, when parsing a file) you can defiantly see the difference.

See: http://msdn.microsoft.com/en-us/ms182279.aspx

And .Length == 0 is even faster if you know that the string is non-null. In fact:

static bool IsNullorEmpty(string s){
  return ((object)s == null) || (s.Length == 0);
}

evildictaitor said:

Programous said:

*snip*

And .Length == 0 is even faster if you know that the string is non-null. In fact:

static bool IsNullorEmpty(string s){
  return ((object)s == null) || (s.Length == 0);
}

I think that is inferred by the example between 1.1 and 2.0 but yes.. any real world performance charts on it?