By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,148 Members | 748 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,148 IT Pros & Developers. It's quick & easy.

default values

P: n/a
Even though CSC does its best to detect use of unassigned variables, it
often misses it... for example if you just declare a double in a class
without assigning a default value, it has a default value of 0 and lets you
use it anyway.

My question is, how can I retrieve the default value for a given type? The
CLR obviously has these defaults stored somewhere and I was hoping to get
hold of it.

I hoped the following code would work, but TypeInitializer is null:

double d = 12;
ConstructorInfo con = d.GetType().TypeInitializer;
Console.WriteLine(con.Invoke(new object[] { }));

Any ideas?
Nov 16 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
John,
My question is, how can I retrieve the default value for a given type?


The default is all bits zeroed out, meaning 0 or 0.0 for numeric
types, false for bools and null for reference types.

For value types, you get the default value when using the default
constructor.

double d = new double(); // effectively the same as double d = 0.0;

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 16 '05 #2

P: n/a
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
John,
My question is, how can I retrieve the default value for a given type?


The default is all bits zeroed out, meaning 0 or 0.0 for numeric
types, false for bools and null for reference types.

For value types, you get the default value when using the default
constructor.

double d = new double(); // effectively the same as double d = 0.0;

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Nov 16 '05 #3

P: n/a
John,

It's actually quite simple. You can use reflection to determine whether
or not the type derives from ValueType in some way. If it does, then you
can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference
type, and the default value is null.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just be 0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
John,
My question is, how can I retrieve the default value for a given type?


The default is all bits zeroed out, meaning 0 or 0.0 for numeric
types, false for bools and null for reference types.

For value types, you get the default value when using the default
constructor.

double d = new double(); // effectively the same as double d = 0.0;

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.


Nov 16 '05 #4

P: n/a
Right, but that won't work for Guid, DateTime or String (to name a few).
Isn't there a method somewhere in the framework that just returns the
default value for a given type?

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine whether or not the type derives from ValueType in some way. If it does, then you
can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference
type, and the default value is null.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't
just be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
John,

>My question is, how can I retrieve the default value for a given type?
The default is all bits zeroed out, meaning 0 or 0.0 for numeric
types, false for bools and null for reference types.

For value types, you get the default value when using the default
constructor.

double d = new double(); // effectively the same as double d = 0.0;

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.



Nov 16 '05 #5

P: n/a
John,

Yes, actually it would. With Guid and DateTime, since they are
structures, they have default constructors, which you can get through
reflection and call through reflection (once you have the type).

With a string, it is not a value type, so the default value for a string
is null, which the algorithm that I detailed in my previous post will return
to you.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Right, but that won't work for Guid, DateTime or String (to name a few).
Isn't there a method somewhere in the framework that just returns the
default value for a given type?

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine

whether
or not the type derives from ValueType in some way. If it does, then you
can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference type, and the default value is null.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't

just
be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
> John,
>
> >My question is, how can I retrieve the default value for a given

type? >
> The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> types, false for bools and null for reference types.
>
> For value types, you get the default value when using the default
> constructor.
>
> double d = new double(); // effectively the same as double d = 0.0;
>
>
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.



Nov 16 '05 #6

P: n/a

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine
whether
or not the type derives from ValueType in some way. If it does, then you
can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference
type, and the default value is null.
The only problem is most value types don't have default constructors(I think
MC++ allowed this for a while, but don't think any other languages did). The
new int() style syntax supported by C# is actually a syntactic sugar for the
initobj instruction, which tells the CLR to zero out a given value type.
Unfortunatly the langage as it stands doesn't support any syntax to
initialize a variable to its default. Tthe C# 2.0 .default operator should
give the behaviour the OP is looking for, if I understand him correctly, but
I havn't taken the time to verify it again in the spec preview so it could
just be an artifact of the current build, but I don't think so.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just

be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
> John,
>
> >My question is, how can I retrieve the default value for a given type?
>
> The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> types, false for bools and null for reference types.
>
> For value types, you get the default value when using the default
> constructor.
>
> double d = new double(); // effectively the same as double d = 0.0;
>
>
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.



Nov 16 '05 #7

P: n/a
If you run GetConstructor on the value type it returns null though...
doesn't look like any of the value types can provide a default constructor.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:OZ**************@TK2MSFTNGP12.phx.gbl...
John,

Yes, actually it would. With Guid and DateTime, since they are
structures, they have default constructors, which you can get through
reflection and call through reflection (once you have the type).

With a string, it is not a value type, so the default value for a string is null, which the algorithm that I detailed in my previous post will return to you.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Right, but that won't work for Guid, DateTime or String (to name a few).
Isn't there a method somewhere in the framework that just returns the
default value for a given type?

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine

whether
or not the type derives from ValueType in some way. If it does, then you can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference type, and the default value is null.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
> Yes, that may be true -- but, given an arbitrary value type, how do I > programmatically retrieve the default value for that type? It can't

just
be
> 0 bits, because for a string (for example) that won't work.
>
> I'd have hoped that the boxed equivalent of the value type would have a
> constructor, but GetConstructor returns null.
>
> "Mattias Sjögren" <ma********************@mvps.org> wrote in message
> news:e4**************@TK2MSFTNGP11.phx.gbl...
> > John,
> >
> > >My question is, how can I retrieve the default value for a given

type?
> >
> > The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> > types, false for bools and null for reference types.
> >
> > For value types, you get the default value when using the default
> > constructor.
> >
> > double d = new double(); // effectively the same as double d =

0.0; > >
> >
> >
> > Mattias
> >
> > --
> > Mattias Sjögren [MVP] mattias @ mvps.org
> > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> > Please reply only to the newsgroup.
>
>



Nov 16 '05 #8

P: n/a
I suppose this answers my question... although it's disappointing the
initobj instruction isn't exposed through the language.

Thanks.

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OK**************@TK2MSFTNGP10.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine
whether
or not the type derives from ValueType in some way. If it does, then you can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference type, and the default value is null.
The only problem is most value types don't have default constructors(I

think MC++ allowed this for a while, but don't think any other languages did). The new int() style syntax supported by C# is actually a syntactic sugar for the initobj instruction, which tells the CLR to zero out a given value type.
Unfortunatly the langage as it stands doesn't support any syntax to
initialize a variable to its default. Tthe C# 2.0 .default operator should
give the behaviour the OP is looking for, if I understand him correctly, but I havn't taken the time to verify it again in the spec preview so it could
just be an artifact of the current build, but I don't think so.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just
be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
> John,
>
> >My question is, how can I retrieve the default value for a given

type? >
> The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> types, false for bools and null for reference types.
>
> For value types, you get the default value when using the default
> constructor.
>
> double d = new double(); // effectively the same as double d = 0.0;
>
>
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.



Nov 16 '05 #9

P: n/a
John,

You actually don't need to get a constructor, you can just call the
version of CreateInstance that takes just the type, it will create an
instance with the bits zeroed out, like this:

// Get the type.
Type pobjIntType = typeof(int);

// Create an instance.
object pobjInt = Activator.CreateInstance(pobjIntType);

Of course, you only run this code if you have a value type, otherwise,
you just return null (for reference types). The full code I would use is:

public static object GetDefaultValue(Type type)
{
// If type is null, throw an exception.
if (type == null)
// Throw an exception.
throw new ArgumentNullException("type");

// Check to see if the type is a value type.
// If it is not, return null.
if (!type.IsValueType)
// Return null.
return null;

// Create an instance of the value type.
return Activator.CreateInstance(type);
}
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
If you run GetConstructor on the value type it returns null though...
doesn't look like any of the value types can provide a default constructor.
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in message news:OZ**************@TK2MSFTNGP12.phx.gbl...
John,

Yes, actually it would. With Guid and DateTime, since they are
structures, they have default constructors, which you can get through
reflection and call through reflection (once you have the type).

With a string, it is not a value type, so the default value for a string
is null, which the algorithm that I detailed in my previous post will

return
to you.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Right, but that won't work for Guid, DateTime or String (to name a few). Isn't there a method somewhere in the framework that just returns the
default value for a given type?

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in
message news:eG*************@TK2MSFTNGP12.phx.gbl...
> John,
>
> It's actually quite simple. You can use reflection to determine
whether
> or not the type derives from ValueType in some way. If it does,
then
you
> can just use the default constructor to generate a value with the

bits > zeroed out. If it does not derive from ValueType, then it is a

reference
> type, and the default value is null.
>
> Hope this helps.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mv*@spam.guard.caspershouse.com
>
> "John Wood" <sp**@isannoying.com> wrote in message
> news:uu**************@TK2MSFTNGP09.phx.gbl...
> > Yes, that may be true -- but, given an arbitrary value type, how do I > > programmatically retrieve the default value for that type? It
can't just
> be
> > 0 bits, because for a string (for example) that won't work.
> >
> > I'd have hoped that the boxed equivalent of the value type would

have
a
> > constructor, but GetConstructor returns null.
> >
> > "Mattias Sjögren" <ma********************@mvps.org> wrote in message > > news:e4**************@TK2MSFTNGP11.phx.gbl...
> > > John,
> > >
> > > >My question is, how can I retrieve the default value for a given type?
> > >
> > > The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> > > types, false for bools and null for reference types.
> > >
> > > For value types, you get the default value when using the default > > > constructor.
> > >
> > > double d = new double(); // effectively the same as double d =

0.0; > > >
> > >
> > >
> > > Mattias
> > >
> > > --
> > > Mattias Sjögren [MVP] mattias @ mvps.org
> > > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> > > Please reply only to the newsgroup.
> >
> >
>
>



Nov 16 '05 #10

P: n/a
Daniel,

While you can not get a default constructor in .NET through reflection,
you can still create a default instance of the value type through the static
CreateInstance method on the Activator class. You just have to pass the
type and it will know what to do with it.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OK**************@TK2MSFTNGP10.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in message news:eG*************@TK2MSFTNGP12.phx.gbl...
John,

It's actually quite simple. You can use reflection to determine
whether
or not the type derives from ValueType in some way. If it does, then you can just use the default constructor to generate a value with the bits
zeroed out. If it does not derive from ValueType, then it is a reference type, and the default value is null.
The only problem is most value types don't have default constructors(I

think MC++ allowed this for a while, but don't think any other languages did). The new int() style syntax supported by C# is actually a syntactic sugar for the initobj instruction, which tells the CLR to zero out a given value type.
Unfortunatly the langage as it stands doesn't support any syntax to
initialize a variable to its default. Tthe C# 2.0 .default operator should
give the behaviour the OP is looking for, if I understand him correctly, but I havn't taken the time to verify it again in the spec preview so it could
just be an artifact of the current build, but I don't think so.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just
be
0 bits, because for a string (for example) that won't work.

I'd have hoped that the boxed equivalent of the value type would have a
constructor, but GetConstructor returns null.

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...
> John,
>
> >My question is, how can I retrieve the default value for a given

type? >
> The default is all bits zeroed out, meaning 0 or 0.0 for numeric
> types, false for bools and null for reference types.
>
> For value types, you get the default value when using the default
> constructor.
>
> double d = new double(); // effectively the same as double d = 0.0;
>
>
>
> Mattias
>
> --
> Mattias Sjögren [MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.



Nov 16 '05 #11

P: n/a

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uO**************@TK2MSFTNGP10.phx.gbl...
Daniel,

While you can not get a default constructor in .NET through reflection,
you can still create a default instance of the value type through the
static
CreateInstance method on the Activator class. You just have to pass the
type and it will know what to do with it.

Yeah...most likely its using initobj at that, :). I wasn't considering
Activator.CreateInstance.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OK**************@TK2MSFTNGP10.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote

in
message news:eG*************@TK2MSFTNGP12.phx.gbl...
> John,
>
> It's actually quite simple. You can use reflection to determine
> whether
> or not the type derives from ValueType in some way. If it does, then you > can just use the default constructor to generate a value with the bits
> zeroed out. If it does not derive from ValueType, then it is a reference > type, and the default value is null.


The only problem is most value types don't have default constructors(I

think
MC++ allowed this for a while, but don't think any other languages did).

The
new int() style syntax supported by C# is actually a syntactic sugar for

the
initobj instruction, which tells the CLR to zero out a given value type.
Unfortunatly the langage as it stands doesn't support any syntax to
initialize a variable to its default. Tthe C# 2.0 .default operator
should
give the behaviour the OP is looking for, if I understand him correctly,

but
I havn't taken the time to verify it again in the spec preview so it
could
just be an artifact of the current build, but I don't think so.
>
> Hope this helps.
>
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mv*@spam.guard.caspershouse.com
>
> "John Wood" <sp**@isannoying.com> wrote in message
> news:uu**************@TK2MSFTNGP09.phx.gbl...
>> Yes, that may be true -- but, given an arbitrary value type, how do I
>> programmatically retrieve the default value for that type? It can't just > be
>> 0 bits, because for a string (for example) that won't work.
>>
>> I'd have hoped that the boxed equivalent of the value type would have
>> a
>> constructor, but GetConstructor returns null.
>>
>> "Mattias Sjögren" <ma********************@mvps.org> wrote in message
>> news:e4**************@TK2MSFTNGP11.phx.gbl...
>> > John,
>> >
>> > >My question is, how can I retrieve the default value for a given type? >> >
>> > The default is all bits zeroed out, meaning 0 or 0.0 for numeric
>> > types, false for bools and null for reference types.
>> >
>> > For value types, you get the default value when using the default
>> > constructor.
>> >
>> > double d = new double(); // effectively the same as double d = 0.0;
>> >
>> >
>> >
>> > Mattias
>> >
>> > --
>> > Mattias Sjögren [MVP] mattias @ mvps.org
>> > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
>> > Please reply only to the newsgroup.
>>
>>
>
>



Nov 16 '05 #12

P: n/a
Ah! I hadn't considered trying CreateInstance. That works great, thanks!

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@TK2MSFTNGP10.phx.gbl...
John,

You actually don't need to get a constructor, you can just call the
version of CreateInstance that takes just the type, it will create an
instance with the bits zeroed out, like this:

// Get the type.
Type pobjIntType = typeof(int);

// Create an instance.
object pobjInt = Activator.CreateInstance(pobjIntType);

Of course, you only run this code if you have a value type, otherwise,
you just return null (for reference types). The full code I would use is:

public static object GetDefaultValue(Type type)
{
// If type is null, throw an exception.
if (type == null)
// Throw an exception.
throw new ArgumentNullException("type");

// Check to see if the type is a value type.
// If it is not, return null.
if (!type.IsValueType)
// Return null.
return null;

// Create an instance of the value type.
return Activator.CreateInstance(type);
}
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
If you run GetConstructor on the value type it returns null though...
doesn't look like any of the value types can provide a default

constructor.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote

in
message news:OZ**************@TK2MSFTNGP12.phx.gbl...
John,

Yes, actually it would. With Guid and DateTime, since they are
structures, they have default constructors, which you can get through
reflection and call through reflection (once you have the type).

With a string, it is not a value type, so the default value for a

string
is null, which the algorithm that I detailed in my previous post will

return
to you.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John Wood" <sp**@isannoying.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
> Right, but that won't work for Guid, DateTime or String (to name a few). > Isn't there a method somewhere in the framework that just returns the > default value for a given type?
>
> "Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
> message news:eG*************@TK2MSFTNGP12.phx.gbl...
> > John,
> >
> > It's actually quite simple. You can use reflection to determine > whether
> > or not the type derives from ValueType in some way. If it does, then you
> > can just use the default constructor to generate a value with the bits > > zeroed out. If it does not derive from ValueType, then it is a
reference
> > type, and the default value is null.
> >
> > Hope this helps.
> >
> >
> > --
> > - Nicholas Paldino [.NET/C# MVP]
> > - mv*@spam.guard.caspershouse.com
> >
> > "John Wood" <sp**@isannoying.com> wrote in message
> > news:uu**************@TK2MSFTNGP09.phx.gbl...
> > > Yes, that may be true -- but, given an arbitrary value type, how do
I
> > > programmatically retrieve the default value for that type? It can't > just
> > be
> > > 0 bits, because for a string (for example) that won't work.
> > >
> > > I'd have hoped that the boxed equivalent of the value type would

have
a
> > > constructor, but GetConstructor returns null.
> > >
> > > "Mattias Sjögren" <ma********************@mvps.org> wrote in message > > > news:e4**************@TK2MSFTNGP11.phx.gbl...
> > > > John,
> > > >
> > > > >My question is, how can I retrieve the default value for a given > type?
> > > >
> > > > The default is all bits zeroed out, meaning 0 or 0.0 for numeric > > > > types, false for bools and null for reference types.
> > > >
> > > > For value types, you get the default value when using the default > > > > constructor.
> > > >
> > > > double d = new double(); // effectively the same as double d

= 0.0;
> > > >
> > > >
> > > >
> > > > Mattias
> > > >
> > > > --
> > > > Mattias Sjögren [MVP] mattias @ mvps.org
> > > > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> > > > Please reply only to the newsgroup.
> > >
> > >
> >
> >
>
>



Nov 16 '05 #13

P: n/a
John Wood <sp**@isannoying.com> wrote:
Yes, that may be true -- but, given an arbitrary value type, how do I
programmatically retrieve the default value for that type? It can't just be
0 bits, because for a string (for example) that won't work.


String isn't a value type though - it's a reference type, so the
default value for a string variable is null.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #14

P: n/a
John Wood <sp**@isannoying.com> wrote:
Even though CSC does its best to detect use of unassigned variables, it
often misses it...


No, it doesn't miss anything - you're simply allowed to use the default
value of instance/static members, whereas unassigned *local* variables
don't have any default value, and you can't use them until they're
definitely assigned.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #15

P: n/a
Something I never fully understood. There's no difference as far as I see...
an unassigned local variable is just as ambiguous as an unassigned member
variable.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <sp**@isannoying.com> wrote:
Even though CSC does its best to detect use of unassigned variables, it
often misses it...


No, it doesn't miss anything - you're simply allowed to use the default
value of instance/static members, whereas unassigned *local* variables
don't have any default value, and you can't use them until they're
definitely assigned.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #16

P: n/a
John Wood <sp**@isannoying.com> wrote:
Something I never fully understood. There's no difference as far as I see...
an unassigned local variable is just as ambiguous as an unassigned member
variable.


There's no ambiguity - it has a very specific default value, and the
time at which that value is assigned to it is well-specified.

The reason for making unassigned local variables an error but not
unassigned member variables is that the flow is much more guaranteed
through a method than uses of a class. For instance, take the
property/variable combo:

string name;
public string Name
{
get { return name; }
set { name = value; }
}

There's absolutely no guarantee what order things will be called in -
so there *has* to be a specification about what will happen if the
"getter" is called before the "setter". With a local variable, however,
you can almost always make sure that the first assignment is a useful
one, and that no "reads" occur before that time. It's only very
occasionally that you need to specify a dummy initial value because the
compiler can't tell that you'll actually always overwrite the initial
value with a "real" value before you read the variable for the first
time.

Would you prefer that every member variable had to have an explicit
assignment at declaration? Or that declaration of a local variable also
implicitly included an assignment even if one was not present?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #17

P: n/a
Sure, there's no implicit order to the code that runs in a class, which is
what i meant by 'missing' it.

Either the variables get assigned a default value and therefore don't need
to be initialized, or they do need to be initialized... seems like it has it
both ways here.

If the compiler is capable of assigning a default value, then why shouldn't
the same logic apply to a class?

I think it makes sense to have a default value assigned to a value type, and
not require you to initialize in both cases -- after all it has one when
it's created anyway, forcing you to set it up to a different value after
it's been constructed is just a waste isn't it?

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <sp**@isannoying.com> wrote:
Something I never fully understood. There's no difference as far as I see... an unassigned local variable is just as ambiguous as an unassigned member variable.


There's no ambiguity - it has a very specific default value, and the
time at which that value is assigned to it is well-specified.

The reason for making unassigned local variables an error but not
unassigned member variables is that the flow is much more guaranteed
through a method than uses of a class. For instance, take the
property/variable combo:

string name;
public string Name
{
get { return name; }
set { name = value; }
}

There's absolutely no guarantee what order things will be called in -
so there *has* to be a specification about what will happen if the
"getter" is called before the "setter". With a local variable, however,
you can almost always make sure that the first assignment is a useful
one, and that no "reads" occur before that time. It's only very
occasionally that you need to specify a dummy initial value because the
compiler can't tell that you'll actually always overwrite the initial
value with a "real" value before you read the variable for the first
time.

Would you prefer that every member variable had to have an explicit
assignment at declaration? Or that declaration of a local variable also
implicitly included an assignment even if one was not present?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #18

P: n/a
John Wood <sp**@isannoying.com> wrote:
Sure, there's no implicit order to the code that runs in a class, which is
what i meant by 'missing' it.

Either the variables get assigned a default value and therefore don't need
to be initialized, or they do need to be initialized... seems like it has it
both ways here.
Nope. The only difference is between local variables and member
variables. Reference types and value types all have default values. I
don't see what's "both ways" about it.
If the compiler is capable of assigning a default value, then why shouldn't
the same logic apply to a class?
Do you mean why isn't there a constructor called for reference types as
well? There's a perfectly good default value for reference types -
null. Bear in mind that not every class *has* a parameterless
constructor. If you're not talking about that, please explain what
you're after again.
I think it makes sense to have a default value assigned to a value type, and
not require you to initialize in both cases -- after all it has one when
it's created anyway, forcing you to set it up to a different value after
it's been constructed is just a waste isn't it?


If you're talking about local variables, they *aren't* logically
assigned a value until they're specifically assigned one. I'm still not
sure what change you're suggesting though - could you be more explicit?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #19

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
I think it makes sense to have a default value assigned to a value type, and not require you to initialize in both cases -- after all it has one when
it's created anyway, forcing you to set it up to a different value after
it's been constructed is just a waste isn't it?


If you're talking about local variables, they *aren't* logically
assigned a value until they're specifically assigned one. I'm still not
sure what change you're suggesting though - could you be more explicit?


I guess I wasn't being clear enough, sorry about that.

Thinking about it further, my opinion is that it actually makes sense to
explicitly initialize *all* value type variables, whether local or member
level. I like everything to be explicit, and I think this is more consistent
with the C# philosophy (where casting is also explicit, for example). For
member level, initialization could occur as part of the declaration, or in
the constructor(s).

I think the default null value for reference types makes sense and should be
implicit.

Do you disagree with that?
Nov 16 '05 #20

P: n/a
John Wood <sp**@isannoying.com> wrote:
If you're talking about local variables, they *aren't* logically
assigned a value until they're specifically assigned one. I'm still not
sure what change you're suggesting though - could you be more explicit?


I guess I wasn't being clear enough, sorry about that.

Thinking about it further, my opinion is that it actually makes sense to
explicitly initialize *all* value type variables, whether local or member
level. I like everything to be explicit, and I think this is more consistent
with the C# philosophy (where casting is also explicit, for example). For
member level, initialization could occur as part of the declaration, or in
the constructor(s).

I think the default null value for reference types makes sense and should be
implicit.

Do you disagree with that?


Yes - if reference type default values are going to be implicit, why
shouldn't value type default values? That particularly applies if
you're arguing for consistency!

If you want everything to be explicit, there's nothing to *stop* you
from assigning to members when you declare them - but I don't see why
it should be enforced. It's not like they have undefined values
otherwise or anything nasty like that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #21

P: n/a
> Yes - if reference type default values are going to be implicit, why
shouldn't value type default values? That particularly applies if
you're arguing for consistency!

Because it's clear that a reference type can have a value of 'unset', which
is null. Value types, however, can never be 'unset', so they must have a
value -- and it's not clear to the person reading the code what that value
might be. Sure you learn these things as you go, and I suppose you can look
up documentation, but I don't recall seeing a list of default values for
valuetypes in the language spec (I may be wrong), and there's the
possibility that other implementations of the CLR may provide different
defaults.

They could at least have provided a warning for it...
Nov 16 '05 #22

P: n/a
John Wood <j@ro.com> wrote:
Yes - if reference type default values are going to be implicit, why
shouldn't value type default values? That particularly applies if
you're arguing for consistency!
Because it's clear that a reference type can have a value of 'unset', which
is null. Value types, however, can never be 'unset', so they must have a
value -- and it's not clear to the person reading the code what that value
might be.
It's clear to anyone who is familiar with the language, IMO. It's not a
particularly obscure piece of the language - it's well documented, it's
usually covered fairly well in books, etc.
Sure you learn these things as you go, and I suppose you can look
up documentation, but I don't recall seeing a list of default values for
valuetypes in the language spec (I may be wrong)
You are:

http://www.jaggersoft.com/csharp_standard/12.2.htm
and there's the possibility that other implementations of the CLR may
provide different defaults.
No there isn't - the specification for what the default value is is in
the C# language spec. That in turn relies on the CLR spec. Any
conformant CLR will give the same values.
They could at least have provided a warning for it...


I don't see why one is necessary, frankly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #23

P: n/a
> It's clear to anyone who is familiar with the language, IMO. It's not a
particularly obscure piece of the language - it's well documented, it's
usually covered fairly well in books, etc.

I'd be willing to bet that less than half of C# developers can recall the
default value of a datetime type off the top of their head...

If you're so comfortable with default values, then why don't you advocate
automatic default value assignment to local variable declarations?
Nov 16 '05 #24

P: n/a
John Wood <j@ro.com> wrote:
It's clear to anyone who is familiar with the language, IMO. It's not a
particularly obscure piece of the language - it's well documented, it's
usually covered fairly well in books, etc.
I'd be willing to bet that less than half of C# developers can recall the
default value of a datetime type off the top of their head...
Then if they care about the value of the variable before it's first
assigned elsewhere, they should set the value explicitly. There's
nothing stopping you from doing that, is there?

(Care to lay any bets about what proportion of C# programmers know the
default value of an int, btw?)
If you're so comfortable with default values, then why don't you advocate
automatic default value assignment to local variable declarations?


Because there, it's almost always wrong. The compiler *can* make sure
that the initial value is usefully set (in almost every case) so
there's no point in *not* being explicit.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #25

P: n/a
> > If you're so comfortable with default values, then why don't you
advocate
automatic default value assignment to local variable declarations?
Because there, it's almost always wrong.

Why so?
The compiler *can* make sure
that the initial value is usefully set (in almost every case) And so it can at the member level. It just needs to check that an assignment
is made to that variable in either the declaration or the constructor(s).
so there's no point in *not* being explicit.

Consequently there's no point in not being explicit in member variables
either?
Nov 16 '05 #26

P: n/a
John Wood <j@ro.com> wrote:
If you're so comfortable with default values, then why don't you advocate automatic default value assignment to local variable declarations?


Because there, it's almost always wrong.

Why so?


Apart from the reasons elsewhere, I feel that member variables are
actually different in nature to local variables. They're less transient
- they represent state, and sometimes state has natural defaults. Local
variables are used during an action, and as such don't "linger" -
somehow that makes a default value less useful for them, although at
the moment I'd be hard pressed to express it better than that.
The compiler *can* make sure
that the initial value is usefully set (in almost every case)

And so it can at the member level. It just needs to check that an assignment
is made to that variable in either the declaration or the constructor(s).


No, that's not the same thing. For local variables, the compiler can
tell when the variable is first read. For member variables, it can't.
Yes, it could enforce that you had to assign something as you suggested
- but that would mean a lot of assignments which simply aren't
necessary.
so there's no point in *not* being explicit.

Consequently there's no point in not being explicit in member variables
either?


I believe there is - but I can see I'm not going to convince you. I
hope you can at least see that making the rules different for reference
type variables and value type variables would lead to *less*
consistency, not more.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #27

P: n/a
> Apart from the reasons elsewhere, I feel that member variables are
actually different in nature to local variables...although at
the moment I'd be hard pressed to express it better than that. I'll give you a chance to express it better another time... otherwise this
argument will go on forever!
For local variables, the compiler can tell when the variable is first read. For member variables, it can't.
It sounds like you're suggesting that you may have member variables that are
never read? Otherwise, what difference does it make? As long as it's
assigned a value at declaration or in the constructor, it shouldn't matter
when it's read.
I hope you can at least see that making the rules different for reference
type variables and value type variables would lead to *less*
consistency, not more.

Actually not really! Sorry!
Reference types are, by nature, references to something, in fact I see them
as a container of sorts. I think it's quite natural to assume that by
default this container is empty, what else could it possibly refer to? It's
an obvious default... much like 0 would be for an integer, it's just that
valuetypes get a bit more complicated than integers...

Oh well, perhaps we should just agree to disagree...

Nov 16 '05 #28

P: n/a
John Wood <j@ro.com> wrote:
For local variables, the compiler can tell when the variable is first
read. For member variables, it can't. It sounds like you're suggesting that you may have member variables that are
never read? Otherwise, what difference does it make? As long as it's
assigned a value at declaration or in the constructor, it shouldn't matter
when it's read.


No - the difference is that with a member variable which isn't assigned
any value in the constructor or in the declaration, it may or may not
be read before a value is first assigned. For instance:

string name;
public string Name
{
get { return name; }
set { name = value; }
}

Is the Name property going to be set or fetched first? The compiler has
no way of knowing.

Compare this with the local variable case, where the compiler can see
*every* attempt to read or write it.
I hope you can at least see that making the rules different for reference
type variables and value type variables would lead to *less*
consistency, not more.

Actually not really! Sorry!
Reference types are, by nature, references to something, in fact I see them
as a container of sorts. I think it's quite natural to assume that by
default this container is empty, what else could it possibly refer to? It's
an obvious default... much like 0 would be for an integer, it's just that
valuetypes get a bit more complicated than integers...

Oh well, perhaps we should just agree to disagree...


I suspect so.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #29

P: n/a
> No - the difference is that with a member variable which isn't assigned
any value in the constructor or in the declaration, it may or may not
be read before a value is first assigned. For instance:

As I said, it shouldn't matter *when* it's read. It can be assumed it'll be
read at some point, otherwise it wouldn't have been declared.

The likelihood is, even the programmer can't be sure what order the code
will run. In fact, this ambiguity provides even more basis for forcing an
explicit assignment during initialization.
Nov 16 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.