locked
string.Empty vs "" RRS feed

  • Question

  • User389365672 posted

    Hello,

    I was wondering if there's any difference (from the compiler standpoint of view) whether I'm passing string.Empty or "" as parameter to the function.

    thx in advance

    Friday, March 31, 2006 10:33 AM

All replies

  • User-2041805088 posted

    This is a pointless debate in the developer world, but "" creates an object instance while String.Empty does not. I generally tend to use String.Empty over "".

    HTH,
    Ryan

    Friday, March 31, 2006 10:53 AM
  • User-967169866 posted
    Yeah.  String.Empty is a read-only that returns "".  Since "" is actually a value type, it'll create that object anyways, but yeah.  I tend to use String.Empty also.  I believe it's faster, but I really don't have the core internals to prove it.
    Friday, March 31, 2006 4:58 PM
  • User390817712 posted

      Since "" is actually a value type, it'll create that object anyways, but yeah.  I tend to use String.Empty also. 

    Actually, since it is still a string, it's a reference type ;)

    Thursday, April 6, 2006 11:26 AM
  • User1416329745 posted

      Since "" is actually a value type, it'll create that object anyways, but yeah.  I tend to use String.Empty also. 

    Actually, since it is still a string, it's a reference type ;)

    Kay,

    This is the beauty of these forums because when you tell other people they are confused about something for  making a mistake you can make the same mistake, '''' is sometimes used by object developers to deal with ANSI SQL null  because as the CLR team's head Brad Abrams said Strings are reference types that thinks they are value types.  We are human.

    Thursday, April 6, 2006 2:21 PM
  • User-967169866 posted
    You're absolutely right.  I'm actually blushing.  haha  It's just one of those things that basically creates a shallow copy when entering methods.  It's one of those reference types that doesn't really pass around a reference, but rather creates a shallow copy so any changes in the called method doesn't refect the altered value in the calling method.

    If that makes sense.  :) 
    Thursday, April 6, 2006 2:25 PM
  • User1416329745 posted
    Strings are Immutable that is the CS term for it.  LOL   And have a nice day.
    Thursday, April 6, 2006 2:29 PM
  • User-967169866 posted
    Kay,

    This is the beauty of these forums because when you tell other people they are confused about something for  making a mistake you can make the same mistake, '''' is sometimes used by object developers to deal with ANSI SQL null  because as the CLR team's head Brad Abrams said Strings are reference types that thinks they are value types.  We are human.



    Caddre, that is the beauty of the forums.  The string being a reference type instead of value type is a common one, and it's something I did know.  I just jumped the gun and typed before thinking.  This is quite a bit different than being "confused".

    Also, I believe ANSI Sql's Nulls are totally different from an empty string.  Where in the world do people actually use "" to deal with ANSI SQL null?  I always thought "object developers" had objects defined to map efficiently and correctly to other objects.. being that "" in ANSI SQL is completely different than "<null>"

    Thursday, April 6, 2006 2:40 PM
  • User1416329745 posted

    I will not dignify that with an answer.

    http://blogs.msdn.com/somasegar/archive/2005/08/11/450640.aspx

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    <o:p> </o:p>

     

     

    Thursday, April 6, 2006 3:16 PM
  • User-967169866 posted
    what does int? have to do with ""?  a nullable type doesn't dignify anything in regards to using "" in place of an ANSI SQL's null value.. int? x = DBNull.Value returns Error    2    Cannot implicitly convert type 'System.DBNull' to 'int?'   So where are you going with this?

    edited:
    Caddre, did you read that blog?  It talks about nullable types that was introduced to c#2.0.  Meaning..

    int xyz;

    if (xyz != null) {
        // this was not possible in previous versions of .net
    }

    It's to remove the need to explicitly set a value to value types.

    Thursday, April 6, 2006 6:34 PM
  • User1574399284 posted

    This is a pointless debate in the developer world, but "" creates an object instance while String.Empty does not. I generally tend to use String.Empty over "".

    HTH,
    Ryan

    Why is it pointless? String.Empty is a whole lot more typing than "".
     
    There is a performance difference but it's pretty minor. In the tests below, the "" operations loop took up 15.85 to 15.88 seconds, while the String.Empty operations loop took up 15.82 to 15.87 seconds.
     
            private void button3_Click(object sender, EventArgs e)
            {
                DateTime dt = DateTime.Now;
                string s = "";
                for (int i = 0; i < 1000000000; i++)
                {
                    if (s == "")
                    {
                        s = "";
                    }
                }
                TimeSpan ts = new TimeSpan(DateTime.Now.Ticks - dt.Ticks);
                textBox1.Text = ts.ToString();
            }
     
            private void button4_Click(object sender, EventArgs e)
            {
                DateTime dt = DateTime.Now;
                string s = String.Empty;
                for (int i = 0; i < 1000000000; i++)
                {
                    if (s == String.Empty)
                    {
                        s = String.Empty;
                    }
                }
                TimeSpan ts = new TimeSpan(DateTime.Now.Ticks - dt.Ticks);
                textBox1.Text = ts.ToString();
            }
    Friday, April 7, 2006 4:51 AM
  • User-2041805088 posted
    Why is it pointless? String.Empty is a whole lot more typing than "".
    There is a performance difference but it's pretty minor.
     
    1) I've read this too many times, but nobody has the research to proove it when they claim it.
    2) The difference is really minor. I can see how this might be important in a large scale project, but other than that it's like comparing apples and oranges.
     
    Ryan
    Friday, April 7, 2006 8:58 AM
  • User763059395 posted

      Since "" is actually a value type, it'll create that object anyways, but yeah.  I tend to use String.Empty also. 

    Actually, since it is still a string, it's a reference type ;)

    However strings are immutable, which in a high level over view means they act like a value type.  In addition I also think the compiler checkes for other strings with the same signature to cut down on memory use.  I could be wrong on the previous statement, however all that being said I am still an advocate of String.Empty because it is cleaner and on the off chance an empty string ever changes to "*" my programs are all set.  [:D]
    Friday, April 7, 2006 10:38 AM
  • User253898925 posted

    Thanks to all contributors. This question arise several times . I took Ryan reply as answer of my long lasting doubt.

    Friday, September 26, 2008 7:29 AM
  • User-319574463 posted

    StyleCop requires string.Empty over an empty string. - Given its pedigree, I accept its advice in the matter.

    Saturday, September 27, 2008 7:30 AM
  • User1574399284 posted

    As far as I'm concerned, it's a question of productivity vs. performance, not a question of performance or correctness alone. If you really want to sit there and type S-t-r-i-n-g-.-E-m-p-t-y, go right ahead. It's worth it if you have an awful lot of empty strings in loops. ;) 

    That said, I once created a macro (as a result of reading this thread, a couple years ago), that would detect when I typed "" and replace it with String.Empty. I removed it after a few weeks because it was so distracting and I never got use to the fugly presence of all that code ("String.Empty") for such a simple thing.

    Tuesday, September 30, 2008 3:22 AM