CODEWITHSUNDEEP
c#reflectiontypes
Mishax
Mishax

Reputation: 4582

difference between GetType() and GetType().UnderlyingSystemType

I have read the definition of "UnderlyingSystemType" namely that it "Indicates the type provided by the common language runtime that represents this type."

There is a related link on SO at When does the UnderlyingSystemType differ from the current Type instance but I cannot tell from the answers if it is actually at all possible to have an object whose type would be different from the UnderlyingSytemType.

I recently learned about CLS compliance, and that unsigned ints are not CLS compliant. And I was really hopeful that maybe that would do it, that the non-CLS compliant types might have a different underlying type, but that is not the case.

For what it's worth, the code I used to test is:

Byte    t01 = 1;
SByte   t02 = 1;
Int16   t03 = 1;
UInt16  t04 = 1;
Int32   t05 = 1;
UInt32  t06 = 1;
Int64   t07 = 1;
UInt64  t08 = 1;
Single  t09 = 1;
Double  t10 = 1;
Decimal t11 = 1;
Console.WriteLine(t01.GetType().Equals(t01.GetType().UnderlyingSystemType));
Console.WriteLine(t02.GetType().Equals(t02.GetType().UnderlyingSystemType));
Console.WriteLine(t03.GetType().Equals(t03.GetType().UnderlyingSystemType));
Console.WriteLine(t04.GetType().Equals(t04.GetType().UnderlyingSystemType));
Console.WriteLine(t05.GetType().Equals(t05.GetType().UnderlyingSystemType));
Console.WriteLine(t06.GetType().Equals(t06.GetType().UnderlyingSystemType));
Console.WriteLine(t07.GetType().Equals(t07.GetType().UnderlyingSystemType));
Console.WriteLine(t08.GetType().Equals(t08.GetType().UnderlyingSystemType));
Console.WriteLine(t09.GetType().Equals(t09.GetType().UnderlyingSystemType));
Console.WriteLine(t10.GetType().Equals(t10.GetType().UnderlyingSystemType));
Console.WriteLine(t11.GetType().Equals(t11.GetType().UnderlyingSystemType));

When run, I just get a bunch of trues.

My question is is there a situation in which an underlying system type of an object can be different from its type? And what is the purpose of this distinction, is it merely to allow the definition of hypothetical types that cannot be instantiated? I can't even create a new Type using the new keyword. And all of the properties of Type are get-only, so I'm lost as to what this feature does. Is the distinction useful in other languages, maybe?

Upvotes: 3

Views: 1781

Answers (1)

Tim S.
Tim S.

Reputation: 56536

Type is an abstract class. The most common implementation you'll see is RuntimeType, which is what objects typically are, but anyone can create an implementation of Type. RuntimeType's UnderlyingSystemType will just return the same RuntimeType. As far as I've seen, this is only really significant if you have a method that takes a Type or construct such a type locally, not if you get an object and call GetType. Here's an example to help you understand:

class Program
{
    static void Main(string[] args)
    {
        // creates a type whose methods and properties are all like Int32, but with an UnderlyingSystemType of string
        var type = new MyType(typeof(int));
        Console.WriteLine(type.FullName); // prints System.Int32
        Console.WriteLine(type.UnderlyingSystemType.FullName); // prints System.String
    }
}
class MyType : TypeDelegator //this extends Type, which is an abstract class
{
    public MyType(Type t) : base(t) { }
    public override Type UnderlyingSystemType
    {
        get
        {
            return typeof(string);
        }
    }
}

Upvotes: 4

Related Questions