By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,857 Members | 1,793 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,857 IT Pros & Developers. It's quick & easy.

string.Empty

P: n/a
I have been told that it is a good idea to *always* declare string variables
with a default value of string.Empty - for cases where an initial value is
not known... like this:

string myString = string.Empty; // do this
string myString; // do not do this

Questions
1. Is that a good rule?
2. If so, why? If not, why not?

Thanks!
Aug 22 '07 #1
Share this Question
Share on Google+
35 Replies


P: n/a
Smithers wrote:
I have been told that it is a good idea to *always* declare string variables
with a default value of string.Empty - for cases where an initial value is
not known... like this:

string myString = string.Empty; // do this
string myString; // do not do this

Questions
1. Is that a good rule?
No.
2. If so, why? If not, why not?
Generally speaking, if a rule says "always" and it involves restricting
you above and beyond what the language allows, it's not a good rule.

In this particular case, I see no reason at all that initializing string
variables with null is in appropriate in a variety of situations.

Initializing with string.Empty (or the equivalent) is desirable when you
want to always be able to assume the string is initialized to an
instance, and an empty string is a useful value. But to say that doing
do is _always_ the right thing to do is wrong.

Pete
Aug 22 '07 #2

P: n/a
Hi,
"Smithers" <A@B.comwrote in message
news:Ow**************@TK2MSFTNGP04.phx.gbl...
>I have been told that it is a good idea to *always* declare string
variables with a default value of string.Empty - for cases where an initial
value is not known... like this:
Not idea why you want to do that.
string myString = string.Empty; // do this
string myString; // do not do this

You know that those two lines are not the same right? String is a reference
type, that means that in the second line it will be unassigned (referencing
null for lack of a better way of saying).
The first line assign it to an instance. Now if you have a type where you
want to use as a default String.Empty then it makes sense.

But that is far from being *always*
Aug 22 '07 #3

P: n/a
Smithers wrote:
I have been told that it is a good idea to *always* declare string variables
with a default value of string.Empty - for cases where an initial value is
not known... like this:

string myString = string.Empty; // do this
string myString; // do not do this

Questions
1. Is that a good rule?
No rule that says you should *always* do something no matter what the
situation is ever a good rule. All rules have exceptions.
2. If so, why? If not, why not?
I have seen, though not often, scenarios where it was important to know
if the field was uninitialized or if it was set to a value of "".
Following the above rule, that distinction would no longer be possible.
--
Tom Porterfield
Aug 22 '07 #4

P: n/a
Smithers wrote:
[...]
So, yes - I botched the OP here because the rule talks about
string.Empty
vs.
""
as opposed to string.empty vs null (which I put in the OP).

Anyway I've heard this rule from Jesse Lilberty as well. So give that at
least two well published authors speak of it, I wanted to understand the
reasoning behind it. Thus the OP here.
I discovered recently that in spite of string pooling, the literal ""
and String.Empty are not equivalent. I didn't explore it any further to
see if there was a way I could get "" and string.Empty to be pooled to
the same string, but the default behavior didn't appear to.

Since as far as I know, the string represented by string.Empty will
always exist, you can avoid having a new empty string added to your
string constant pool by always using that instead of "". However, I
doubt there's much different beyond that. As long as string pooling is
enabled, the worst that using "" instead of string.Empty should cause is:

1) the addition of a single extra string in the string constant pool

2) very slightly slower comparisons between one empty string and
another when they aren't using the same version of the empty string (I'm
assuming here that Equals() for strings checks for reference equality
first, so if the constants are the same reference, this would shortcut
the need to compare length and contents, speeding things very slightly).

In other words, I can't imagine that there's any truly significant
difference between the two. They aren't literally the same, at least in
some situations, but you are unlikely to ever notice the difference in a
real-world application.

Pete
Aug 22 '07 #5

P: n/a
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
You know that those two lines are not the same right? String is a reference
type, that means that in the second line it will be unassigned (referencing
null for lack of a better way of saying).
The variable being unassigned and the variable having an assigned value
of null are very different things.

If you do:

string myString;

for a *member* variable, the variable is assigned the value null. If
you do it for a *local* variable, the variable isn't assigned at all -
its value isn't null, it *has* no value yet, as far as the compiler is
concerned.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 22 '07 #6

P: n/a
Tom Porterfield <tp******@mvps.orgwrote:
I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.
Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

I wouldn't like to say why, given the IL for the static constructor of
String, but there we go.
Personally I prefer "" to string.Empty - I find it clearer. I've never
seen any good reasons presented for using string.Empty instead.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 22 '07 #7

P: n/a
Peter Duniho wrote:
I discovered recently that in spite of string pooling, the literal ""
and String.Empty are not equivalent. I didn't explore it any further to
see if there was a way I could get "" and string.Empty to be pooled to
the same string, but the default behavior didn't appear to.
Hmmm, this appears to be true. The following:

string a = string.Empty;
string b = "";
string c = string.Empty;
string d = "";

Console.WriteLine(object.ReferenceEquals(a, b));
Console.WriteLine(object.ReferenceEquals(a, c));
Console.WriteLine(object.ReferenceEquals(b, d));

Yields the results:

False
True
True
Since as far as I know, the string represented by string.Empty will
always exist, you can avoid having a new empty string added to your
string constant pool by always using that instead of "". However, I
doubt there's much different beyond that. As long as string pooling is
enabled, the worst that using "" instead of string.Empty should cause is:

1) the addition of a single extra string in the string constant pool

2) very slightly slower comparisons between one empty string and
another when they aren't using the same version of the empty string (I'm
assuming here that Equals() for strings checks for reference equality
first, so if the constants are the same reference, this would shortcut
the need to compare length and contents, speeding things very slightly).

In other words, I can't imagine that there's any truly significant
difference between the two. They aren't literally the same, at least in
some situations, but you are unlikely to ever notice the difference in a
real-world application.
Agreed.
--
Tom Porterfield
Aug 22 '07 #8

P: n/a
Jon Skeet [C# MVP] wrote:
Tom Porterfield <tp******@mvps.orgwrote:
>As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}
Yep, did a small test, though slightly different, and confirmed the same
(see reply to Peter Duniho).
I wouldn't like to say why, given the IL for the static constructor of
String, but there we go.
Hehe. I'll poke around in it when I get a chance.
Personally I prefer "" to string.Empty - I find it clearer. I've never
seen any good reasons presented for using string.Empty instead.
--
Tom Porterfield
Aug 22 '07 #9

P: n/a
Jonathan Wood <jw***@softcircuits.comwrote:
Yes, that is a very different question.

I would agree and I always use String.Empty rather than "" in this case. In
theory at least, String.Empty is an existing string while "" is a new one.
"" is only new the very first time it's used in an assembly.
And so using String.Empty will result in one less string declaration (even
if it contains no characters).

That said, it's hard to always know what is going on internally within the
compiler and libraries. It is not inconceivable that the compiler could
automatically detect and then replace "" with String.Empty, although I do
not recommend assuming that behavior.
You can and *should* assume that string literals are interned, as it's
part of the C# specification. It's not limited to empty strings. If you
have the code:

string x = "hello";
string y = "he"+"llo";
Console.WriteLine(object.ReferenceEquals(x,y));

then the spec guarantees that "True" will be printed out.
Quite why it's not happening for string.Empty vs "" isn't clear at the
moment, but in the general case it's fine.

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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 22 '07 #10

P: n/a
Jon,
string x = "hello";
string y = "he"+"llo";
Console.WriteLine(object.ReferenceEquals(x,y));

then the spec guarantees that "True" will be printed out.
Wow, sure enough. I didn't realize that.

I wonder how much overhead is associated with that feature. For every value
assigned to a String, it sounds like the libs looks up a list of all
existing strings to see if there's a match.
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?
As a long-time C/C++ and assembly language programmer, tiny performance hits
are something I care about for the simple reason that you can end up with
hundreds or even thousands of them in a substantial application. In fact,
one thing that really bothers me about .NET is a lot of the extra overhead
by many parts of how it is designed.

That said, I'm not sure there would be any performance hit in this case
given the information you gave above. I can imagine there could be some tiny
bit of additional memory used. Other than that, it sounds like the library
would simply look to see if "" is already a string and, if so, the string
wouldn't be used any further.

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

Aug 22 '07 #11

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
Tom Porterfield <tp******@mvps.orgwrote:
I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}
True but....

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

will output true, "strings" are interned "objects" are not......
Willy.

Aug 22 '07 #12

P: n/a
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

True but....

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

will output true, "strings" are interned "objects" are not......
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 22 '07 #13

P: n/a
Jonathan Wood <jw***@softcircuits.comwrote:
string x = "hello";
string y = "he"+"llo";
Console.WriteLine(object.ReferenceEquals(x,y));

then the spec guarantees that "True" will be printed out.

Wow, sure enough. I didn't realize that.

I wonder how much overhead is associated with that feature. For every value
assigned to a String, it sounds like the libs looks up a list of all
existing strings to see if there's a match.
No - only every string constant, and that only needs to be done once.
The JIT compiler checks whether or not the string has already been
interned when it compiles a ldstr instruction.

In other words, there's very little overhead associated with it.
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?

As a long-time C/C++ and assembly language programmer, tiny performance hits
are something I care about for the simple reason that you can end up with
hundreds or even thousands of them in a substantial application. In fact,
one thing that really bothers me about .NET is a lot of the extra overhead
by many parts of how it is designed.
In this case, the overhead is one-off and really, really tiny.

Even in C/C++ and assembly, the old adage about not micro-optimising
until you know where there's a problem holds true.
That said, I'm not sure there would be any performance hit in this case
given the information you gave above. I can imagine there could be some tiny
bit of additional memory used. Other than that, it sounds like the library
would simply look to see if "" is already a string and, if so, the string
wouldn't be used any further.
No - otherwise the examples we've looked at so far wouldn't have shown
"" and string.Empty to be different references.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 22 '07 #14

P: n/a
Jon,
>I wonder how much overhead is associated with that feature. For every
value
assigned to a String, it sounds like the libs looks up a list of all
existing strings to see if there's a match.

No - only every string constant, and that only needs to be done once.
The JIT compiler checks whether or not the string has already been
interned when it compiles a ldstr instruction.
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());
Even in C/C++ and assembly, the old adage about not micro-optimising
until you know where there's a problem holds true.
That's an issue for another discussion.
>That said, I'm not sure there would be any performance hit in this case
given the information you gave above. I can imagine there could be some
tiny
bit of additional memory used. Other than that, it sounds like the
library
would simply look to see if "" is already a string and, if so, the string
wouldn't be used any further.

No - otherwise the examples we've looked at so far wouldn't have shown
"" and string.Empty to be different references.
Well, that certainly would explain it, although there could potentially be
other explanations.

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

Aug 22 '07 #15

P: n/a
Jon Skeet [C# MVP] wrote:
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. :-)
--
Tom Porterfield
Aug 22 '07 #16

P: n/a
<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.
Aug 23 '07 #17

P: n/a
Smithers wrote:
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
Aug 23 '07 #18

P: n/a
Thanks for the explanation. Now, I'm off to the "intern pool".

:-)
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...
Smithers wrote:
>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

Aug 23 '07 #19

P: n/a

On Aug 22, 11:48 pm, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
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....0/14/2585.aspx

Aug 23 '07 #20

P: n/a
Jonathan Wood <jw***@softcircuits.comwrote:
No - only every string constant, and that only needs to be done once.
The JIT compiler checks whether or not the string has already been
interned when it compiles a ldstr instruction.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 23 '07 #21

P: n/a
UL-Tomten <to****@gmail.comwrote:
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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 23 '07 #22

P: n/a
Willy Denoyette [MVP] wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
>Tom Porterfield <tp******@mvps.orgwrote:
>I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

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.

--
Göran Andersson
_____
http://www.guffa.com
Aug 23 '07 #23

P: n/a
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.

Aug 23 '07 #24

P: n/a
DeveloperX wrote:
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
Aug 23 '07 #25

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
Willy Denoyette [MVP] <wi*************@telenet.bewrote:
Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

True but....

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

will output true, "strings" are interned "objects" are not......

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.
Aug 23 '07 #26

P: n/a
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

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
Tom Porterfield <tp******@mvps.orgwrote:
I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

I wouldn't like to say why, given the IL for the static constructor of
String, but there we go.
Personally I prefer "" to string.Empty - I find it clearer. I've never
seen any good reasons presented for using string.Empty instead.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Aug 23 '07 #27

P: n/a
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.
Aug 23 '07 #28

P: n/a
Chris Shepherd <ch**@nospam.chsh.cawrote:

<snip>
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.?
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Aug 23 '07 #29

P: n/a
With Orcas targeting framework 3.5 and 3.0 the result from that test is
false.

"John" <jo**@donotspam.invalidwrote in message
news:eh**************@TK2MSFTNGP06.phx.gbl...
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

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com.. .
>Tom Porterfield <tp******@mvps.orgwrote:
>I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

I wouldn't like to say why, given the IL for the static constructor of
String, but there we go.
Personally I prefer "" to string.Empty - I find it clearer. I've never
seen any good reasons presented for using string.Empty instead.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Aug 24 '07 #30

P: n/a
Which test?

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

"Graeme Bradbury" <gr*************@bcs.org.ukwrote in message
news:FC**********************************@microsof t.com...
With Orcas targeting framework 3.5 and 3.0 the result from that test is
false.

"John" <jo**@donotspam.invalidwrote in message
news:eh**************@TK2MSFTNGP06.phx.gbl...
>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

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP********************@msnews.microsoft.com. ..
>>Tom Porterfield <tp******@mvps.orgwrote:
I am of course, assuming it's generally understood that a definition
without assignment will be null.

As strings are interned, a reference to string.Empty would be the same
as a reference to "", so I can't see that there is any difference from
that standpoint. After that, it looks like just coding style to me.

Nope, string.Empty and "" won't be the same reference, at least they're
not guaranteed to be. The code below prints False on my box:

using System;

public class Test
{
static void Main()
{
object x = "";
object y = string.Empty;
Console.WriteLine (x==y);
}
}

I wouldn't like to say why, given the IL for the static constructor of
String, but there we go.
Personally I prefer "" to string.Empty - I find it clearer. I've never
seen any good reasons presented for using string.Empty instead.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Aug 24 '07 #31

P: n/a

The test in the message with message-id <u5AJNwV5HHA.
37**@TK2MSFTNGP06.phx.gbl>.

On Aug 24, 4:02 pm, "Jonathan Wood" <jw...@softcircuits.comwrote:
Which test?

"Graeme Bradbury" <graeme.bradb...@bcs.org.ukwrote in message
With Orcas targeting framework 3.5 and 3.0 the result from that test is
false.
Aug 24 '07 #32

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
>
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?

--
Jon Skeet - <sk***@pobox.com>
Here is one stab at it.
It fits better with String.IsNullOrEmpty()

- Michael Starberg
Sep 12 '07 #33

P: n/a
On Sep 12, 3:05 pm, "Michael S" <n...@no.nowrote:
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

Sep 12 '07 #34

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
On Sep 12, 3:05 pm, "Michael S" <n...@no.nowrote:
>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
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
Sep 14 '07 #35

P: n/a
Michael S <no@no.nowrote:
Sure. I actually think it is a trivial discussion.
Pretty much, yes.
What I don't like is that string is sealed.
Whereas I'd be worried about a string that *isn't* sealed. I know that
string is sealed and immutable - therefore I can pass strings around
safely, knowing that nothing can change them at all.
For webdevelopment I'd like a SafeString that is never null.
I can't say I've ever found it much of a problem, to be honest. The ??
operator in C# 2 makes it easier, too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 17 '07 #36

This discussion thread is closed

Replies have been disabled for this discussion.