purpose of CreateInstance<T>

[Dan Holmes]

Isn't CreateInstance(typeof(int)) the same as CreateInstance<int>()?

i don't understand how this method helps anything.

dan

 

[antoan]

Isn't CreateInstance(typeof(int)) the same as CreateInstance<int>()?

i don't understand how this method helps anything.

dan

CreateInstance<T> is an example of a generic method. The generic
parameter T enables you to invoke it with different data types eg:

CreateInstance<CustomDataType>()
CreateInstance<string>()
CreateInstance<T>()

An advantage of a generic method is that you can implement the
behaviour/algorithm once and apply it to different types.

Hope this helps.

A

 

[Dan Holmes]

CreateInstance<T> is an example of a generic method. The generic
parameter T enables you to invoke it with different data types eg:

CreateInstance<CustomDataType>()
CreateInstance<string>()
CreateInstance<T>()

An advantage of a generic method is that you can implement the
behaviour/algorithm once and apply it to different types.

Hope this helps.

A

I guess i figured the non-generic version could do all of that too.

 

[Chris Chilvers]

I guess i figured the non-generic version could do all of that too.

I really cannot see the point of the generic version of CreateInstance.
All it appears to be to me is an unsafe way to call new T() as it
doesn't enforce that T has a parameterless constructor.

Thus:
String a = Activator.CreateInstance<String>();
will compile but you just get a run-time error.

But if you knew the type to put in the generic why not just call:
MyClass a = new MyClass()

 

[Barry Kelly]

Isn't CreateInstance(typeof(int)) the same as CreateInstance<int>()?

i don't understand how this method helps anything.

It's the implementation of ": new()" and "new T()". It also leaves an
avenue to the CLR folks to dynamically bind to the corresponding
constructor so that reflection doesn't have to be used.

It isn't currently optimized (check it out with SOS and !u) - but that
path is available to future runtimes.

Test program:

---8<---
using System;

class App
{
class A {}
class B : A {}

static void Main()
{
A a = Activator.CreateInstance<A>();
B b = Activator.CreateInstance<B>();
}
}
--->8---

The contents of App.Main, unassembled with WinDbg, SOS, !u:

---8<---
mov ecx,0x9230f8
(MD: System.Activator.CreateInstance[[App+A, Test]]())

call mscorlib_ni+0x2edd58 (793add58)
(System.Activator.CreateInstance[[System.__Canon, mscorlib]](),
mdToken: 06000399)

mov ecx,0x9231b0
(MD: System.Activator.CreateInstance[[App+B, Test]]())

call mscorlib_ni+0x2edd58 (793add58)
(System.Activator.CreateInstance[[System.__Canon, mscorlib]](),
mdToken: 06000399)

ret
--->8---

You can see there that the actual method called for both invocations of
CreateInstance is the preJITted one at 793add58, so it must be using
reflection in order to get the job done.

-- Barry

 

[antoan]

I really cannot see the point of the generic version of CreateInstance.
All it appears to be to me is an unsafe way to call new T() as it
doesn't enforce that T has a parameterless constructor.

Thus:
String a = Activator.CreateInstance<String>();
will compile but you just get a run-time error.

But if you knew the type to put in the generic why not just call:
MyClass a = new MyClass()

It is simply a factory method that allows you to deffer the
specification of the data type it acts/produces until you actually need
to declare it eg

MyClass Activator.CreateInstance<Activator>();

The whole point here is that you can REUSE the same generic method to
create strongly typed instances of the data type you want by way of
specifying the generic type parameter which in this example is
"MyClass". The advantage of dealing with strong types as opposed to
object(s) as in the case of:

object Activator.CreateInstance(Type);

is that you dont have to suffer performance penalties by having to box -
unbox value types from the heap as well casting back to the required
type from object.

As the sdk docs say it regarding the method discussed: "Creates an
instance of the specified type using the constructor that best matches
the specified parameter".

you should probably check out the the msdn generics guide:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/csharp_generics.asp

 

[Nicholas Paldino [.NET/C# MVP]]

You are missing the point somewhat.

If you are specifying the type in the Generic call, like so:

MyClass mc = Activator.CreateInstance<MyClass>();

Why not just do:

MyClass mc = new MyClass();

Yes, the CreateInstance<T> is type safe, but you have to declare that
type at compile time. If you have to declare the type, then you might as
well call the constructor directly.

If you call Activator.CreateInstance, then you also run the risk of the
type not having a default constructor. If you call the constructor
directly, you will get a compile-time error, as opposed to a run time error.
Compile time errors are ALWAYS preferable.

That being said, I can't see a reason to EVER use
Activator.CreateInstance<T>.

 

[Mattias Sjögren]

That being said, I can't see a reason to EVER use
Activator.CreateInstance<T>.

You may be using it without knowing it. The compiler compiles new T()
for a generic type parameter T to a call to
Activator.CreateInstace<T>(). Try running ILDASM on the following

class Foo<T> where T : new() { T t = new T(); }


Mattias

 

[Barry Kelly]

That being said, I can't see a reason to EVER use
Activator.CreateInstance<T>.

The compiler needs it for generic new() constraints.

-- Barry