views:

727

answers:

9

Hello!

This isn't really an issue, however I am curious. When I save a string in lets say an DataRow, it is cast to Object. When I want to use it, I have to cast it ToString. As far as I know there are several ways of doing this, first is

string name = (string)DataRowObject["name"]; //valid since I know it's a string

and another one is:

string name = DataRowObject["name"].ToString();

I am interested in what is the difference between both? Is the first more efficient? (This is just a speculation, in my head ToString() method is implemented by some looping mechanism where just casting it "could" be faster, however this is just a "gut feeling" I have).

Is there even a faster / more elegant way of doing this?

Can anyone clear this up for me?

+2  A: 

If you know it is a String then by all means cast it to a String. Casting your object is going to be faster than calling a virtual method.

Edit: Here are the results of some benchmarking:

============ Casting vs. virtual method ============
cast 29.884 1.00
tos  33.734 1.13

I used Jon Skeet's BenchmarkHelper like this:

using System;
using BenchmarkHelper;

class Program
{
    static void Main()
    {
     Object input = "Foo";
     String output = "Foo";

     var results 
           = TestSuite.Create("Casting vs. virtual method", input, output)
         .Add(cast)
         .Add(tos)
         .RunTests()
         .ScaleByBest(ScalingMode.VaryDuration);

     results.Display(ResultColumns.NameAndDuration | ResultColumns.Score,
       results.FindBest());
    }

    static String cast(Object o)
    {
     return (String)o;
    }

    static String tos(Object o)
    {
     return o.ToString();
    }
}

So it appears that casting is in fact slightly faster than calling ToString().

Andrew Hare
@Andrew: Have you benchmarked that? It may well have changed, but last time I benchmarked it I found that the virtual method was actually faster. I didn't expect it to be, but it was.
Jon Skeet
@Jon - No I didn't! I will have to check that out to make sure.
Andrew Hare
+2  A: 

(string), .ToString() and Convert.ToString(..) behave differently as summarised here

AdaTheDev
+3  A: 

Basically in your case it is better to leave type cast because .ToString() may hide bugs. For example, your data base schema changed and name is no longer of string type but with .ToString() your code still works. So in this case it is better to use type cast.

Here is implementation of String.ToString() - nothing special =)

public override string ToString()
{
    return this;
}
Dzmitry Huba
+1 for decompiliing String.ToString()
Patrick McDonald
+3  A: 

Downcasting is a relatively slow operation since CLR has to perform various runtime type-checks. However, in this particular scenario casting to string is more appropriate than calling ToString() for the sake of consistency (you can't call ToInt32 on object, but cast it to int) and maintanability.

Anton Gogolev
It might not be as slow as you think - please see my answer.
Andrew Hare
+7  A: 

The two are intended for different purposes. The ToString method of any object is supposed to return a string representation of that object. Casting is quite different, and the 'as' key word performs a conditional cast, as has been said. The 'as' key word basically says "get me a reference of this type to that object if that object is this type" while ToString says "get me a string representation of that object". The result may be the same in some cases but the two should never be considered interchangeable because, as I said, they exist for different purposes. If your intention is to cast then you should always use a cast, NOT ToString.

from http://www.codeguru.com/forum/showthread.php?t=443873

see also http://bytes.com/groups/net-c/225365-tostring-string-cast

astander
+1  A: 

In this case:

string name = DataRowObject["name"].ToString();

since it is a string, I think that the ToString() method of a string object is simple as:

return this;

so IMHO there is no performance penalty.

PS I'm a Java programmer, so this anwser is only a guess.

dfa
I think DataRowObject has no knowledge of types and stores everything as Objects, so it is definitely not as simple as return this.
martijn_himself
@martjin_himself welcome to the world of Object Orientation, let me introduce you a new friend: Polymorphism.
fortran
@fortran would you mind elaborating? I am aware everything is an Object and polymorphism allows you to treat a string as if it were an Object, however that is irrelevant here, unless I am missing something? cheers
martijn_himself
@dfa sorry what I meant to say is that it is not stored as a string, I wish I could edit comments if they sound a bit harsh :)
martijn_himself
+1  A: 

ToString() does not perform a cast by default. Its purpose is to return a string that represents the type (e.g. "System.Object").

If you want to avoid casting you could try to think of an implementation that is strongly typed (using generics, for example) and avoids DataRowObject altogether.

martijn_himself
+1  A: 

For data object, I suggest you to use "as" keyword like the following code.

string name = DataRowObject["name"] as string;

Please check it before you use value.

if(name != null)
{
    // statement for empty string or it has value
}
else
{
    // statement for no data in this object.    
}
Soul_Master
A: 

I want to make one more comment

If you are going to use casting: string name = (string)DataRowObject["name"] you will get an Exception: Unable to cast object of type 'System.DBNull' to type'System.String' in case if the record in the database table has null value.

In this scenario you have to use: string name = DataRowObject["name"].ToString() or

You have to check for null value like

if(!string.IsNullOrEmpty(DataRowObject["name"].ToString())) { string name = (string)DataRowObject["name"]; } else { //i.e Write error to the log file string error = "The database table has a null value";

}