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

string = "" or = string.Empty?

P: n/a
string = "" or string = string.Empty?
should is the proper way?

Sami
Aug 22 '08 #1
Share this Question
Share on Google+
21 Replies


P: n/a
On Aug 22, 2:36*pm, "Sami" <sam...@ymail.comwrote:
string = "" or string = string.Empty?
should is the proper way?

Sami
string str = string.Empty is the proper and more efficient way.

Thanks,
Aug 22 '08 #2

P: n/a
as*****@woh.rr.com wrote:
On Aug 22, 2:36 pm, "Sami" <sam...@ymail.comwrote:
>string = "" or string = string.Empty?
should is the proper way?

Sami

string str = string.Empty is the proper and more efficient way.

Thanks,
Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.

--
Göran Andersson
_____
http://www.guffa.com
Aug 22 '08 #3

P: n/a
On Aug 22, 3:09*pm, Göran Andersson <gu...@guffa.comwrote:
asha...@woh.rr.com wrote:
On Aug 22, 2:36 pm, "Sami" <sam...@ymail.comwrote:
string = "" or string = string.Empty?
should is the proper way?
Sami
string str = string.Empty is the proper and more efficient way.
Thanks,

Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
Aug 22 '08 #4

P: n/a
On Fri, 22 Aug 2008 12:46:18 -0700, <za***@construction-imaging.comwrote:
>[...]
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.

I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).

Personally I find "" more concise, just as expressive (if not more so) as
String.Empty, and I've never in decades of programming accidently deleted
the entire contents of a string literal. So for me, "" suits my needs
just fine.

Pete
Aug 22 '08 #5

P: n/a
On Fri, 22 Aug 2008 13:11:51 -0700, "Peter Duniho"
<Np*********@nnowslpianmk.comwrote:
>On Fri, 22 Aug 2008 12:46:18 -0700, <za***@construction-imaging.comwrote:
>>[...]
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.

I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.

You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).
Evenif the references are in difference classes in the same project?
>
Personally I find "" more concise, just as expressive (if not more so) as
String.Empty, and I've never in decades of programming accidently deleted
the entire contents of a string literal. So for me, "" suits my needs
just fine.

Pete
Aug 22 '08 #6

P: n/a
Although I prefer the latter of the two, I don't think it makes much
difference.

Personally, I would use string.Length == 0.

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

"Sami" <sa****@ymail.comwrote in message
news:Ou**************@TK2MSFTNGP03.phx.gbl...
string = "" or string = string.Empty?
should is the proper way?

Sami
Aug 22 '08 #7

P: n/a
On Fri, 22 Aug 2008 15:04:17 -0700, Joe Cool <jo*****@home.netwrote:
>[...] At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).

Evenif the references are in difference classes in the same project?
Yes. The pooling isn't restricted to per-class.
Aug 22 '08 #8

P: n/a
Joe Cool wrote:
On Fri, 22 Aug 2008 13:11:51 -0700, "Peter Duniho"
<Np*********@nnowslpianmk.comwrote:
>On Fri, 22 Aug 2008 12:46:18 -0700, <za***@construction-imaging.comwrote:
>>[...]
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
I've been told that string.Empty does not require any user memory, and
every time you reference "" you use a little bit more user memory to
store the literal.
You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).

Evenif the references are in difference classes in the same project?
Even different classes residing in different assemblies loaded in
different app domains.

Arne
Aug 23 '08 #9

P: n/a
Göran Andersson wrote:
as*****@woh.rr.com wrote:
>On Aug 22, 2:36 pm, "Sami" <sam...@ymail.comwrote:
>>string = "" or string = string.Empty?
should is the proper way?

string str = string.Empty is the proper and more efficient way.

Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.

If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.
The classic reason for using names instead of values is
that if you want to change the value, then you only need
to change it one place.

Very good reason. But it does not apply here. You will
never want to change the value of the empty string.

And "" is actually easier to read, so I will consider that
the proper way.

You could forget to put something within the "" but you could
also forget to write something instead of String.Empty - I can
not see the difference.

Arne
Aug 23 '08 #10

P: n/a
On Aug 22, 5:05*pm, Arne Vajhřj <a...@vajhoej.dkwrote:
Göran Andersson wrote:
asha...@woh.rr.com wrote:
On Aug 22, 2:36 pm, "Sami" <sam...@ymail.comwrote:
string = "" or string = string.Empty?
should is the proper way?
string str = string.Empty is the proper and more efficient way.
Well, it's not more efficient as they are both string literals, but the
code more closely resembles the intention.
If you always use string.Empty when you want an empty string, you know
that when you find "" in your code there is something that you
accidentally removed or something that you forgot to put there.

The classic reason for using names instead of values is
that if you want to change the value, then you only need
to change it one place.

Very good reason. But it does not apply here. You will
never want to change the value of the empty string.

And "" is actually easier to read, so I will consider that
the proper way.

You could forget to put something within the "" but you could
also forget to write something instead of String.Empty - I can
not see the difference.

Arne
I personally like to use "", because sometimes you can mistake
string.Empty for being null.
It's essentially the same thing, although there might be some
difference under the hood.
But I believe that string.Empty just does = "", so it's just one more
level of redirection (although I have to check up on the value of
string.Empty)
If you have a doubt about what something does in the .NET Framework,
just google for DotNetReflector and download it. It's a great program
that uses reflection to disassemble the IL code of any .NET assembly
(including mscorlib and the like) and then convert it to C# or some
other languages (although some code is obfuscated).
Aug 23 '08 #11

P: n/a
Jonathan Wood wrote:
Although I prefer the latter of the two, I don't think it makes much
difference.

Personally, I would use string.Length == 0.
And if FxCop is to be believed this is actually the most efficient way --
but it's only applicable if you know the value isn't null. Of course,
there's String.IsNullOrEmpty() for such cases.

Personally, I've never understood why it should make any difference at all.
If the compiler and the jitter don't treat these things as equivalent,
they're the ones that suck, not my code. Making the programmer worry about
the best way to test if strings are empty is not a good division of
responsibilities.

Take a look at http://dotnetperls.com/Content/Empty-String.aspx. Now think
about this: what cool things have you shipped lately that depended on how
fast you tested for empty strings? Do you find programming more enjoyable
worrying about this? Would you enjoy keeping track of a moving target if the
characteristics change in another release of the framework?

--
J.
Aug 23 '08 #12

P: n/a
A short note on efficiency can be found here.

http://www.csharp411.com/stringisnullorempty-shootout/
"Sami" wrote:
string = "" or string = string.Empty?
should is the proper way?

Sami
Aug 23 '08 #13

P: n/a
On Sat, 23 Aug 2008 01:09:10 -0700, Jeroen Mostert <jm******@xs4all.nl>
wrote:
Jonathan Wood wrote:
>Although I prefer the latter of the two, I don't think it makes much
difference.
Personally, I would use string.Length == 0.
And if FxCop is to be believed this is actually the most efficient way
-- but it's only applicable if you know the value isn't null. Of course,
there's String.IsNullOrEmpty() for such cases.
But since the original question was about _assigning_ strings, not
comparing them, whether FxCop is correct or not doesn't matter. It has no
bearing on what the "preferred" way to _assign_ an empty string to a
variable would be.

I do agree with everything else you wrote. Surely the question of
comparing empty strings is significant only in a particularly unusual
program. But that's not what the OP was asking about. :)

Pete
Aug 23 '08 #14

P: n/a
Code_Breaker wrote:
>string = "" or string = string.Empty?
should is the proper way?
A short note on efficiency can be found here.

http://www.csharp411.com/stringisnullorempty-shootout/
Different problem.

Arne
Aug 23 '08 #15

P: n/a
Peter Duniho wrote:
On Sat, 23 Aug 2008 01:09:10 -0700, Jeroen Mostert <jm******@xs4all.nl>
wrote:
>Jonathan Wood wrote:
>>Although I prefer the latter of the two, I don't think it makes much
difference.
Personally, I would use string.Length == 0.
And if FxCop is to be believed this is actually the most efficient way
-- but it's only applicable if you know the value isn't null. Of
course, there's String.IsNullOrEmpty() for such cases.

But since the original question was about _assigning_ strings, not
comparing them, whether FxCop is correct or not doesn't matter. It has
no bearing on what the "preferred" way to _assign_ an empty string to a
variable would be.

I do agree with everything else you wrote. Surely the question of
comparing empty strings is significant only in a particularly unusual
program. But that's not what the OP was asking about. :)
Yes, we're going off on a tangent. But for assigning, I'd like to think the
same line of reasoning applies. Assigning either "" or String.Empty should
make no difference whatsoever (and in this case, unlike empty string
testing, I think it actually doesn't, but I'm not well-versed in CLR
internals enough to positively state it). I suppose you can think of
String.Empty as the language-independent way of writing the empty string
literal -- just in case your language designer forgot to supply a way to
write one...

--
J.
Aug 23 '08 #16

P: n/a
On Sat, 23 Aug 2008 11:35:05 -0700, Jeroen Mostert <jm******@xs4all.nl>
wrote:
Yes, we're going off on a tangent. But for assigning, I'd like to think
the same line of reasoning applies. Assigning either "" or String.Empty
should make no difference whatsoever (and in this case, unlike empty
string testing, I think it actually doesn't, but I'm not well-versed in
CLR internals enough to positively state it).
I don't think there's a good, concise way to describe the framework's
behavior, especially since it varies somewhat from version to version.
For sure, "" is not the same reference as String.Empty under normal
circumstances (that is, simply using whatever the compiler generates).
Even if you try to go through the interning explicitly, different versions
of the framework have different behaviors (see
http://msdn.microsoft.com/en-us/libr...g.intern.aspx).

So, it depends on what you mean by "make no difference whatsoever". :)
Taken literally, I'd say that's a wrong statement, inasmuch as there would
be a detectable difference in code between the two approaches. But taken
more practically, I'd agree...I doubt it would have any real practical
difference. Even when contained in two difference references, as long as
the code doesn't itself assume that two different references imply two
unequal strings, the only possible difference would be with respect to
performance, and surely that difference would be very tiny and not a
bottleneck.
I suppose you can think of String.Empty as the language-independent way
of writing the empty string literal -- just in case your language
designer forgot to supply a way to write one...
I'm having a hard time imagining a language that supports string literals
but not an empty string literal. The language would have to do without
delimiters altogether, which would make it very tricky to have a reliably
way to declare arbitrary string literals. :) At the very least, it would
force the compiler to do a LOT more work (since the compiler would have to
make inferences about the context).

Pete
Aug 23 '08 #17

P: n/a
"Peter Duniho" <Np*********@nnowslpianmk.comwrote:
I'm having a hard time imagining a language that supports string literals
but not an empty string literal. The language would have to do without
delimiters altogether, which would make it very tricky to have a reliably
way to declare arbitrary string literals. :)
Perhaps the source would be rich text, and string literals would be bolded!

Eq.
Aug 23 '08 #18

P: n/a
On Sat, 23 Aug 2008 14:41:05 -0700, Paul E Collins
<fi******************@cl4.orgwrote:
"Peter Duniho" <Np*********@nnowslpianmk.comwrote:
>I'm having a hard time imagining a language that supports string
literals
but not an empty string literal. The language would have to do without
delimiters altogether, which would make it very tricky to have a
reliably
way to declare arbitrary string literals. :)

Perhaps the source would be rich text, and string literals would be
bolded!
Hmmm...data entry could be problematic, assuming you're using a WSYWIG
editor. But RTF, HTML, and I believe things like TeX and Postscript as
well, have no trouble representing a bolded empty string. E.g. "\b\b0" in
RTF or "<b></b>" in HTML. The language itself wouldn't prohibit empty
strings unless it's tied to a specific editor, rather than an actual
rich-text format. And even then, you'd have to pick the editor
specifically such that it doesn't support empty bold text ranges (one
could easily design an editor that does).

But you definitely get points for thinking outside the box. :) Well, I
assume you do, anyway. I don't know who's actually issuing the points or
how you'd receive them, but surely they'd grant you some for that. :)

Pete
Aug 23 '08 #19

P: n/a
You've been told wrong then. At worst, all uses of the explicit literal
"" will use the same object, due to string pooling (I think in C# they
call it interning...same thing).

Assuming that the article listed below is correct, I guess using
"String.Empty" does provide a tiny winnie memory savings :)

http://www.codeproject.com/KB/dotnet/StringEmpty.aspx

Cheers.

Aug 24 '08 #20

P: n/a
>
I personally like to use "", because sometimes you can mistake
string.Empty for being null.
It's essentially the same thing, although there might be some
difference under the hood.
But I believe that string.Empty just does = "", so it's just one more
level of redirection (although I have to check up on the value of
string.Empty)
If you have a doubt about what something does in the .NET Framework,
just google for DotNetReflector and download it. It's a great program
that uses reflection to disassemble the IL code of any .NET assembly
(including mscorlib and the like) and then convert it to C# or some
other languages (although some code is obfuscated).
Empty is a readonly member variable of the String class which is set in
String's default constructor as an empty string literal (IE: ""). But, just
because it is a member variable does NOT mean it isn't treated differently
by the compiler and compiled into more efficient code depending on how it's
called.

HTH,
Mythran
Aug 25 '08 #21

P: n/a
On Mon, 25 Aug 2008 09:46:14 -0700, Mythran <My*****@community.nospam>
wrote:
Empty is a readonly member variable of the String class which is set in
String's default constructor as an empty string literal (IE: ""). But,
just because it is a member variable does NOT mean it isn't treated
differently by the compiler and compiled into more efficient code
depending on how it's called.
In particular, because it's an interned string in a shared DLL (that is, a
DLL that can be shared across multiple processes), there is a potential
tiny savings if one uses _only_ String.Empty, in that the process won't
have to allocate that one extra emtpy string.

If you've got even one "" in your code somewhere though, that would negate
any benefit. And in any case, it's certainly not worth worrying about.

Pete
Aug 25 '08 #22

This discussion thread is closed

Replies have been disabled for this discussion.