80

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?

David Božjak
  • 16,887
  • 18
  • 67
  • 98
  • 5
    I know you mentioned that the Object is a string, but incase you're not sure afraid the returned object is null, you can also cast using "Convert.ToString(DataRowObject["name"]);" This has the added benefit of returning an empty string (string.empty) if the object is null, to avoid any null reference exceptions. – n00b Apr 11 '13 at 20:45

9 Answers9

57

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

Adriaan Stander
  • 162,879
  • 31
  • 289
  • 284
  • 1
    So if I understand this correctly. .ToString will always return a string of the object. While casting will fail if it cant be returned as a string? – Linda Lawton - DaImTo Oct 28 '15 at 09:55
  • 1
    @DaImTo: When you cast an object from type A to type B (if the casting) success, you will have a new object, which you can cast back to A type again. Casting is not change who they are (the core), but change what will they will be looked as. Converting, in common cases, is a one-way ticket. It make a new object (only) represent for the old object. Ex: a student object st when convert toString() will be a string look like student:@1343;43234. do you think you can turn it back into a student which have fields value? – Andiana Apr 17 '16 at 03:06
  • @Andiana In Ref Exam book for c# it says "When creating your own types, you can override ToString to return a string representation of your object. If necessary, you can then create a Parse and TryParse method that converts the string back to the original object. Implementing the IFormattable interface is required so that your object can be used by the Convert class." Could you explain it in the light of what you said earlier. Thank you – Ashraf Alshahawy Feb 21 '17 at 23:09
  • Would string name = DataRowObject["name"] as String; work ? Just curious... – Jack Griffin Oct 15 '19 at 16:57
32

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().

Josh DeLong
  • 475
  • 6
  • 24
Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
16

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
  • 4,493
  • 20
  • 19
5

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
  • 113,561
  • 39
  • 200
  • 288
5

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";

}
VladL
  • 12,769
  • 10
  • 63
  • 83
3

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.    
}
2

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
  • 114,442
  • 31
  • 189
  • 228
  • 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 Jul 23 '09 at 10:14
  • 3
    @martjin_himself welcome to the world of Object Orientation, let me introduce you a new friend: Polymorphism. – fortran Jul 23 '09 at 10:27
  • @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 Jul 23 '09 at 11:05
  • @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 Jul 23 '09 at 11:57
1

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,560
  • 3
  • 18
  • 34
1

I know you mentioned that the Object is a string, but incase you're afraid that the returned object is null, you can also cast using "Convert.ToString(DataRowObject["name"]);" This has the added benefit of returning an empty string (string.empty) if the object is null, to avoid any null reference exceptions (unless of course you want an exception thrown in such cases).

n00b
  • 4,341
  • 5
  • 31
  • 57
  • There is one additional benefit to using the "Convert.ToString" and that is that you can pass in a null value without having an exception thrown. [link](http://msdn.microsoft.com/en-us/library/astxcyeh.aspx) – Remy Jun 28 '13 at 17:56