string.Empty

[Tom Porterfield]

Indeed - but the point of the exercise was to check for equal
references, not equal objects. I think we can all agree that
string.Empty and "" will always refer to equal strings.

Egad, I sure hope so.

 

[Smithers]

<snip>

Not to wander too far off into the weeds here, but... RE:

<< The JIT compiler checks whether or not the string has already been
interned when it compiles a ldstr instruction.>>

What is meant by "interned" in the above sentence? I've seen "interned" used
a couple of times in this thread.

Thanks.

 

[Peter Duniho]

What is meant by "interned" in the above sentence? I've seen "interned" used
a couple of times in this thread.

Huh? I thought everyone knew the answer. The string is "interned" when
it's put to work with no pay.

Oh. Wait, not that's not it.

Seriously: it's essentially the same as a regular string pool as seen in
other languages, except that you can add new strings to the pool at runtime.

The basic idea being that if a given string appears multiple times in
code, each instance of the string can be compiled as a reference to the
single string instance in the "intern pool". That way, you don't wind
up with multiple copies of the same string bloating the compiled
executable. The compiler does this automatically.

Pete

 

[Smithers]

Thanks for the explanation. Now, I'm off to the "intern pool".

 

[UL-Tomten]

so what are the other benefits, if any, of using string.Empty
instead of ""? It looks less clear to me... any of the string.Empty
advocates like to make a case for it?

For me, the reason has always been that I (to quote Brendan
Tompkins[1] "hate having quoted strings in code". Even if "" is a very
special string literal, it is still a string literal, and if your code
contains many string literals scattered about, it could get hard to
debug, at least when these string literals are part of program logic
and not just printouts or composite formatting patterns. string.Empty
might mean to a prospective future toucher of your code that you
expressly want the empty string, whereas "" could mean a string
literal which just happens to be empty. Also, string.Empty is more
consistent with the usage style for constants like Integer.MaxValue,
Timeout.Infinite, etc. So I agree it's a coding style issue.

1: http://codebetter.com/blogs/brendan.tompkins/archive/2003/10/14/2585.aspx

 

[Jon Skeet [C# MVP]]

So the point is you're saying it's compile time overhead. I didn't know "he"
+ "llo" was a constant but that's certainly something that a compiler could
be made to figure out and handle. And, in fact, I see your examples returns
False if I change it like this:

string x = "hello";
string y = "he";
y += "llo";
MessageBox.Show(object.ReferenceEquals(x, y).ToString());

It's partly a compile time overhead, figuring out the constant strings.
There's a *slight* runtime overhead, as the JIT needs to check the
intern pool at each ldstr instruction, but that only happens once (per
instruction).

<snip>

 

[Jon Skeet [C# MVP]]

so what are the other benefits, if any, of using string.Empty
instead of ""? It looks less clear to me... any of the string.Empty
advocates like to make a case for it?

For me, the reason has always been that I (to quote Brendan
Tompkins[1] "hate having quoted strings in code". Even if "" is a very
special string literal, it is still a string literal, and if your code
contains many string literals scattered about, it could get hard to
debug, at least when these string literals are part of program logic
and not just printouts or composite formatting patterns. string.Empty
might mean to a prospective future toucher of your code that you
expressly want the empty string, whereas "" could mean a string
literal which just happens to be empty. Also, string.Empty is more
consistent with the usage style for constants like Integer.MaxValue,
Timeout.Infinite, etc. So I agree it's a coding style issue.

The reason I use Integer.MaxValue etc is that it's clearer than the
numeric equivalent - it's not obvious that the literal *is*
Integer.MaxValue. It's very clear that an empty string is an empty
string.

As a counter-example, if there were an Integer.Zero constant, would you
use that instead of the literal 0?

I really don't buy the 'if I have "" in code then I might not really
want an empty string' argument, I'm afraid. In both cases you'd only
want to change it if you wanted a non-empty string.

I'm slightly less anti-string-literals in general than most people
though. If a string literal only appears once in the code, I'm often
(though not always) happy to have it "inline" rather than as a
constant.

I'm not really trying to persuade anyone to *stop* using string.Empty,
just to say that using "" is perfectly reasonable too

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

True but....

string x = "";
string y = string.Empty;
Console.WriteLine (x==y);

will output true,

Of course it will. The value of the strings are equal.

"strings" are interned "objects" are not......

That's not why. The reason is that when you compare the strings, the
value of the strings are compared, but when you compare the objects, the
references are compared.

If you do like this:

object x = "";
object y = "";
Console.WriteLine(x == y);

It will output true. As the strings are interned, the references that
are stored in the variables are equal.

 

[DeveloperX]

Seriously: it's essentially the same as a regular string pool as seen in
other languages, except that you can add new strings to the pool at runtime.

The basic idea being that if a given string appears multiple times in
code, each instance of the string can be compiled as a reference to the
single string instance in the "intern pool". That way, you don't wind
up with multiple copies of the same string bloating the compiled
executable. The compiler does this automatically.

Pete

I seem to remember this is why it's a bad idea to lock on a string.

So if class A has private string s = "Lock";
and class B has private string s2 = "Lock";

when class A locks s it also locks class B's s2.

I think that's right anyway.

 

[Peter Duniho]

I seem to remember this is why it's a bad idea to lock on a string.

Well, I suppose that's _one_ reason why it's a bad idea to lock on a
string. I'd hardly suggest it's the only reason.

So if class A has private string s = "Lock";
and class B has private string s2 = "Lock";

when class A locks s it also locks class B's s2.

If the strings are both declared as literals like that yes, I'd agree.

There are other ways to generate unique string instances though, so if
you really wanted to lock on a string, you could. In that respect, I
don't think the string class is all that unique; whatever you lock on,
you need to make sure it's unique for best results. It's just that it's
a bit trickier _in certain cases_ with the string class.

I think that's right anyway.

Yes, I do too.

Pete

 

[Willy Denoyette [MVP]]

Indeed - but the point of the exercise was to check for equal
references, not equal objects. I think we can all agree that
string.Empty and "" will always refer to equal strings.

Yep, sorry my bad, did actually miss the other messages in this thread :-(


Willy.

 

[John]

In addition to your point,

The behavior changed from .NET 1.0/1.1 to 2.0. Under the old
versions your test prints True. Have not tested under Orcas
since I am redoing the vm.

John

 

[Chris Shepherd]

I really don't buy the 'if I have "" in code then I might not really

want an empty string' argument, I'm afraid. In both cases you'd only
want to change it if you wanted a non-empty string.

I'm slightly less anti-string-literals in general than most people
though. If a string literal only appears once in the code, I'm often
(though not always) happy to have it "inline" rather than as a
constant.

I tend to agree. Assigning a string to "" signals a clear intent and
probably offers a clearer understanding of what is meant than
string.Empty (if not, this thread probably wouldn't exist). Most
programmers will be immediately familiar with what this does:
string s = "";
Whereas it will require making assumptions and/or researching exactly
what this does:
string s = string.Empty;

I'm not really trying to persuade anyone to *stop* using string.Empty,
just to say that using "" is perfectly reasonable too

Am I correct in assuming that string.Empty will not contain a different
value based on the current system codepage/character set/encoding/etc.?

Chris.

 

[Jon Skeet [C# MVP]]

Am I correct in assuming that string.Empty will not contain a different
value based on the current system codepage/character set/encoding/etc.?

Indeed. It's always equal to "". Unless code is comparing the
references produced, it doesn't matter (from an execution point of
view) whether you use "" or string.Empty.

 

[Graeme Bradbury]

With Orcas targeting framework 3.5 and 3.0 the result from that test is
false.

In addition to your point,

The behavior changed from .NET 1.0/1.1 to 2.0. Under the old
versions your test prints True. Have not tested under Orcas
since I am redoing the vm.

John

 

[Jonathan Wood]

Which test?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

With Orcas targeting framework 3.5 and 3.0 the result from that test is
false.

 

[UL-Tomten]

The test in the message with message-id <u5AJNwV5HHA.
(e-mail address removed)>.

 

[Michael S]

Now, the performance hit of introducing a single new string *once* is
tiny - so what are the other benefits, if any, of using string.Empty
instead of ""? It looks less clear to me... any of the string.Empty
advocates like to make a case for it?

Here is one stab at it.
It fits better with String.IsNullOrEmpty()

- Michael Starberg

 

[Jon Skeet [C# MVP]]

Here is one stab at it.
It fits better with String.IsNullOrEmpty()

In what way? That method name is easily understandable even if you use
"" because you still think of it as "an empty string" anyway.

Jon

 

[Michael S]

In what way? That method name is easily understandable even if you use
"" because you still think of it as "an empty string" anyway.

Jon

Sure. I actually think it is a trivial discussion.

What I don't like is that string is sealed.
For webdevelopment I'd like a SafeString that is never null.

Now I am using a wrapper class for this with implicit cast operators, but it
is uglier.

- Michael Starberg