Shall I now always use String.Empty instead of ""

[anonieko]

In the past I always used "" everywhere for empty string in my code
without a problem.

Now, do you think I should use String.Empty instead of "" (at all
times) ?

Let me know your thoughts.

 

[Guest]

In the past I always used "" everywhere for empty string in my code
without a problem.

Now, do you think I should use String.Empty instead of "" (at all
times) ?

If you're checking for an empty string it's better to use:
String.IsNullOrEmpty(strStringName)
As of .NET 2.0

 

[Morten Wennevik]

Hi,

There is very little difference between the two.

"" is easy to write, easy to read, and near impossible to misunderstand.
It will however create an object where String.Empty would not, but the ""
object is reused throughout the lifespawn of your application so the
difference can therefore be ignored.

Neither will detect a null string so if you can have null strings you need
to either check for that as well or use String.IsNullErEmtpy as Leon
pointed out.

if(str == null || str == "") // or
if(String.IsNullOrEmpty(str))

If, on the other hand, you know you will never get null strings, testing
for String.Length == 0 is the fastest way.

 

[Jon Skeet [C# MVP]]

In the past I always used "" everywhere for empty string in my code
without a problem.

Now, do you think I should use String.Empty instead of "" (at all
times) ?

Which do you find easier to read? That's pretty much the only
difference of any significance, IMO.

 

[Jon Shemitz]

"" is easy to write, easy to read, and near impossible to misunderstand.
It will however create an object where String.Empty would not, but the ""
object is reused throughout the lifespawn of your application so the
difference can therefore be ignored.

I was surprised to read that "" will create an object where
String.Empty will not - surely String.Empty is just a static field
that points to an interned "" constant?

Sure enough, Reflector shows that String.Empty is implemented as

class string
{
static readonly string Empty = "";
}

.... yet the below code shows that while both "" and String.Empty are
interned, "" is not reference-equal to String.Empty. What gives? I
thought the intern table was maintained across assembly boundaries, so
it shouldn't matter that String.Empty comes from mscorlib.dll while ""
comes from the app assembly.

//

using System;

namespace StringEmptyTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Object.ReferenceEquals(String.Empty, ""));
Console.WriteLine(String.IsInterned("") != null);
Console.WriteLine(String.IsInterned(String.Empty) != null);
Console.ReadLine();
}
}
}

 

[Gabriel Lozano-Morán]

And what happens if string interning is disabled? Doesn't this mean that
each time you have a "" in your code that you will have the overhead of
allocating memory on the heap and creating a new string object?

Gabriel

 

[Jon Skeet [C# MVP]]

And what happens if string interning is disabled? Doesn't this mean that
each time you have a "" in your code that you will have the overhead of
allocating memory on the heap and creating a new string object?

String interning isn't something you can enable or disable, as far as
I'm aware - and at that point, the C# language specification is being
violated. I don't alter my programming style in order to suit
situations like that - it's like changing your style to suit a
situation where garbage collection doesn't occur.

 

[Gabriel Lozano-Morán]

See:
http://msdn2.microsoft.com/en-us/li...services.compilationrelaxationsattribute.aspx
http://msdn2.microsoft.com/en-us/library/system.runtime.compilerservices.compilationrelaxations.aspx

Gabriel Lozano-Morán

And what happens if string interning is disabled? Doesn't this mean that
each time you have a "" in your code that you will have the overhead of
allocating memory on the heap and creating a new string object?

String interning isn't something you can enable or disable, as far as
I'm aware - and at that point, the C# language specification is being
violated. I don't alter my programming style in order to suit
situations like that - it's like changing your style to suit a
situation where garbage collection doesn't occur.

 

[Chris Mullins]

String interning isn't something you can enable or disable, as far as
I'm aware - and at that point, the C# language specification is being
violated.

You can't disable it. At least not that I was able to find, and I looked for
quite a while.

I wrote up a blog entry on my findings with string interning and when /
where it can save memory (at least in the case i'm worried about):
http://www.coversant.com/dotnetnuke/Default.aspx?tabid=88&EntryID=24

 

[Jon Skeet [C# MVP]]

See:
http://msdn2.microsoft.com/en-us/library/system.runtime.compilerservi
ces.compilationrelaxationsattribute.aspx

How bizarre. Using that would certainly mean you were no longer using a
language which conformed to the C# language spec. However, you would
have to *explicitly* use that attribute, so again I can't see that it's
actually a consideration to think about in normal coding.

 

[Chris Mullins]

In the past I always used "" everywhere for empty string in my code
without a problem.

Now, do you think I should use String.Empty instead of "" (at all
times) ?

From the Blog at:
http://blogs.msdn.com/brada/archive/2003/04/22/49997.aspx

"" actually creates an object, it will likely be
pulled out of the string intern pool, but still.
while String.Empty creates no object.
so if you are really looking for ultimately
in memory efficiency, I suggest String.Empty.

So there ya have it. String.Empty is obviously a zillion times better than
"".

In all honesty though, I don't think it ever really matters. Certainly not
in any cases I've ever come across. I use string.empty, because I dislike
the look of "".

 

[Dave Sexton]

Hi,

I use string.Empty because that's what everyone I talked to had told me
since the original framework beta.

Personally, I don't really care either way now, but it's just a habit.

If I could shake the OCD involved I might be able to start using "" instead,
which seems cleaner to me

 

[Gabriel Lozano-Morán]

I personally prefer string.Empty over "" in code. It is just a matter of
flavor but it can be a good thing to make it a guideline whether or not you
to use "" vs string.Empty for the team.

Gabriel Lozano-Morán

 

[Dave Sexton]

Hi Gabriel,

I don't think I'd be too concerned if different team members used "" or
string.Empty. I'd leave that up to personal preference. It really isn't
that important, IMO.

 

[Mattias Sjögren]

How bizarre. Using that would certainly mean you were no longer using a

language which conformed to the C# language spec. However, you would
have to *explicitly* use that attribute

Actually the C# 2.0 compiler adds this attribute to all assemblies,
unless you explicitly specify otherwise.

Which part of the spec do you mean this would violate? I know that
previous compiler versions sometimes relied on interning to implement
the switch statement for strings, but that doesn't seem to be the case
anymore.


Mattias

 

[Jon Skeet [C# MVP]]

Actually the C# 2.0 compiler adds this attribute to all assemblies,
unless you explicitly specify otherwise.

Yikes - you're right. Interesting that it doesn't seem to have the
indicated effect. Here's a sample program:

using System;
using System.Diagnostics;

class Test1
{
public static string Empty = "";
}

class Test2
{
public static string Empty = "";
}

class Test
{
static void Main()
{
string s1 = Test1.Empty;
string s2 = Test2.Empty;
Console.WriteLine (object.ReferenceEquals(s1, s2));
}
}

That prints "True" on my box, which will only be true if the strings
are interned. Printing string.IsInterned("x") shows that being interned
too.

Odd. I'm intrigued now...

Which part of the spec do you mean this would violate? I know that
previous compiler versions sometimes relied on interning to implement
the switch statement for strings, but that doesn't seem to be the case
anymore.

From
http://www.jaggersoft.com/csharp_standard/9.4.4.5.htm#string-literal

<quote>
Each string literal does not necessarily result in a new string
instance. When two or more string literals that are equivalent
according to the string equality operator (§14.9.7), appear in the same
assembly, these string literals refer to the same string instance.
</quote>

(I'll have to look at how strings are switched now, too. So much to
look at, so little time...)

 

[Dave Sexton]

Hi Jon,

Apparently, CompilationRelaxations.NoStringInterning only disables string
interning for the NGEN utility. This setting is automatically applied on
all assemblies compiled by the C# 2.0 compiler, as Mattias already
mentioned, and as you've pointed out Interning is certainly not disabled in
2.0

The documentation Gabriel has cited is definitely misleading and should be
updated. I don't believe that C# or .NET provides the ability to disable
string interning in code.

"Starting with the .NET Framework version 2.0, you can override the use of
the intern pool when you use the Native Image Generator (Ngen.exe) to
install an assembly to the native image cache on a local computer. For more
information, see Performance Considerations in the Remarks section for the
Intern property." (and by "property" I think they mean "method"

"String.IsInterned Method"
http://msdn2.microsoft.com/en-us/library/system.string.isinterned.aspx

"The .NET Framework version 2.0 introduces the
CompilationRelaxations.NoStringInterning enumeration member. The
NoStringInterning member marks an assembly as not requiring string-literal
interning. You can apply NoStringInterning to an assembly using the
CompilationRelaxationsAttribute attribute. When you use the Native Image
Generator (Ngen.exe) to install that assembly to the native image cache on
the local computer, string interning is not used."

"String.Intern Method"
http://msdn2.microsoft.com/en-us/library/system.string.intern(vs.80).aspx

--
Dave Sexton

Actually the C# 2.0 compiler adds this attribute to all assemblies,
unless you explicitly specify otherwise.

Yikes - you're right. Interesting that it doesn't seem to have the
indicated effect. Here's a sample program:

using System;
using System.Diagnostics;

class Test1
{
public static string Empty = "";
}

class Test2
{
public static string Empty = "";
}

class Test
{
static void Main()
{
string s1 = Test1.Empty;
string s2 = Test2.Empty;
Console.WriteLine (object.ReferenceEquals(s1, s2));
}
}

That prints "True" on my box, which will only be true if the strings
are interned. Printing string.IsInterned("x") shows that being interned
too.

Odd. I'm intrigued now...

Which part of the spec do you mean this would violate? I know that
previous compiler versions sometimes relied on interning to implement
the switch statement for strings, but that doesn't seem to be the case
anymore.

From
http://www.jaggersoft.com/csharp_standard/9.4.4.5.htm#string-literal

<quote>
Each string literal does not necessarily result in a new string
instance. When two or more string literals that are equivalent
according to the string equality operator (§14.9.7), appear in the same
assembly, these string literals refer to the same string instance.
</quote>

(I'll have to look at how strings are switched now, too. So much to
look at, so little time...)

 

[Jon Shemitz]

Actually the C# 2.0 compiler adds this attribute to all assemblies,
unless you explicitly specify otherwise.

Which part of the spec do you mean this would violate? I know that
previous compiler versions sometimes relied on interning to implement
the switch statement for strings, but that doesn't seem to be the case
anymore.

That's news to me, but a quick test shows that you're right.

That's rather strange - I wonder if they found that the cost of
interning switch input strings was greater than the savings from using
ReferenceEquals instead of Equals (when comparing the input string to
the case tags).

 

[Dave Sexton]

Hi Jon,

Your example code has been bothering me - it should work, however it doesn't
and I can't figure out why

But if you think that's weird, check out the following documentation I found
on MSDN:

"String.Intern Method"
http://msdn2.microsoft.com/en-us/library/system.string.intern.aspx

<quote>
Version Considerations
Starting with the .NET Framework version 2.0, there is a behavioral change
in the Intern method. In the following C# code sequence, the variable str1
is assigned a reference to Empty, the variable str2 is assigned the
reference to Empty that is returned by the Intern method, then the
references contained in str1 and str2 are compared for equality.

string str1 = String.Empty;
string str2 = String.Intern(String.Empty);
if ((object) str1) == ((object) str2) .

In the .NET Framework version 1.1, str1 and str2 are not equal, but starting
in the .NET Framework version 2.0, str1 and str2 are equal.
</quote>

Not in my test :|

string str1 = String.Empty;
string str2 = String.Intern(String.Empty);

// false
Console.WriteLine((object) str1 == (object) str2);

// false
Console.WriteLine((object) string.Empty == (object) "");

// true
Console.WriteLine((object) "" == (object) "");


Using Reflector I verified that string.Empty is assigned the empty literal,
"", in the class constructor (.cctor). I also verified, through testing,
that interning works across assemblies; so I'm stumped here.

The earliest version of the framework that I have installed on my machine is
2.0, verified in Add or Remove Programs. I also have 3.0 installed, if that
makes a difference.

Anyone know what's going on here?

--
Dave Sexton

"" is easy to write, easy to read, and near impossible to misunderstand.
It will however create an object where String.Empty would not, but the ""
object is reused throughout the lifespawn of your application so the
difference can therefore be ignored.

I was surprised to read that "" will create an object where
String.Empty will not - surely String.Empty is just a static field
that points to an interned "" constant?

Sure enough, Reflector shows that String.Empty is implemented as

class string
{
static readonly string Empty = "";
}

... yet the below code shows that while both "" and String.Empty are
interned, "" is not reference-equal to String.Empty. What gives? I
thought the intern table was maintained across assembly boundaries, so
it shouldn't matter that String.Empty comes from mscorlib.dll while ""
comes from the app assembly.

//

using System;

namespace StringEmptyTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Object.ReferenceEquals(String.Empty, ""));
Console.WriteLine(String.IsInterned("") != null);
Console.WriteLine(String.IsInterned(String.Empty) != null);
Console.ReadLine();
}
}
}


--

.NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.

 

[clintonG]

Sorry to go OT -- for a monet -- but you're able to load documentation at
msdn2.microsoft.com?
Quite a few people can not load pages at msdn2 for many weeks now and trying
to figure out why.

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP http://wikimapia.org/#y=43038073&x=-88043838&z=17&l=0&m=h

Hi Jon,

Your example code has been bothering me - it should work, however it
doesn't and I can't figure out why

But if you think that's weird, check out the following documentation I
found on MSDN:

"String.Intern Method"
http://msdn2.microsoft.com/en-us/library/system.string.intern.aspx

<quote>
Version Considerations
Starting with the .NET Framework version 2.0, there is a behavioral change
in the Intern method. In the following C# code sequence, the variable str1
is assigned a reference to Empty, the variable str2 is assigned the
reference to Empty that is returned by the Intern method, then the
references contained in str1 and str2 are compared for equality.

string str1 = String.Empty;
string str2 = String.Intern(String.Empty);
if ((object) str1) == ((object) str2) .

In the .NET Framework version 1.1, str1 and str2 are not equal, but
starting in the .NET Framework version 2.0, str1 and str2 are equal.
</quote>

Not in my test :|

string str1 = String.Empty;
string str2 = String.Intern(String.Empty);

// false
Console.WriteLine((object) str1 == (object) str2);

// false
Console.WriteLine((object) string.Empty == (object) "");

// true
Console.WriteLine((object) "" == (object) "");


Using Reflector I verified that string.Empty is assigned the empty
literal, "", in the class constructor (.cctor). I also verified, through
testing, that interning works across assemblies; so I'm stumped here.

The earliest version of the framework that I have installed on my machine
is 2.0, verified in Add or Remove Programs. I also have 3.0 installed, if
that makes a difference.

Anyone know what's going on here?

--
Dave Sexton

"" is easy to write, easy to read, and near impossible to misunderstand.
It will however create an object where String.Empty would not, but the
""
object is reused throughout the lifespawn of your application so the
difference can therefore be ignored.

I was surprised to read that "" will create an object where
String.Empty will not - surely String.Empty is just a static field
that points to an interned "" constant?

Sure enough, Reflector shows that String.Empty is implemented as

class string
{
static readonly string Empty = "";
}

... yet the below code shows that while both "" and String.Empty are
interned, "" is not reference-equal to String.Empty. What gives? I
thought the intern table was maintained across assembly boundaries, so
it shouldn't matter that String.Empty comes from mscorlib.dll while ""
comes from the app assembly.

//

using System;

namespace StringEmptyTest
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Object.ReferenceEquals(String.Empty, ""));
Console.WriteLine(String.IsInterned("") != null);
Console.WriteLine(String.IsInterned(String.Empty) != null);
Console.ReadLine();
}
}
}


--

.NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.