nullable types is a struct ?

[Tony Johansson]

Hello!

Jon skeet answer this question in a previous mail for several days ago if
nullable type is a reference or a value type?

With the following answer.
It's a struct - otherwise there'd be relatively little value in having
it instead of having explicit access to the boxed types.

But what does the answer actually mean?

//Tony

[Jon Skeet [C# MVP]]

On Sep 30, 9:13*am, "Tony Johansson" <t.johans...@lo gica.comwrote:

Jon skeet answer this question in a previous mail for several days ago if
nullable type is a reference or a value type?

It's a value type.

With the following answer.
It's a struct - otherwise there'd be relatively little value in having
it instead of having explicit access to the boxed types.

But what does the answer actually mean?

It's still a struct, so there's no separate heap object created. In
other words, it's like this:

struct Nullable<Twhere T : struct
{
private T value;
private boolean hasValue;

// Properties, constructor etc
}

An alternative would have been to make a "wrapper class":

class Nullable<Twhere T : struct
{
private T value;
}

where you'd have a genuine null reference instead of a reference to an
instance. However, that then puts more pressure on the GC etc.

There are a few ways in which nullable types aren't like other
structs:
o The null value boxes to a null reference
o You can unbox from a boxed value of the non-nullable type, or from a
null reference
o You can't use it as the type argument for something with a "where
T : struct" constraint
o You can use null to compare/assign the null value of the nullable
type (i.e. hasValue = false)

Jon

[Peter Morris]

System.Nullable is a ValueType. It is a generic class, so the reference to
its value is not boxed, the value is also stored as a ValueType. In
addition to holding the value it as a "bool HasValue" property that
indicates whether the value has been set or not.
Does that help?

[Jon Skeet [C# MVP]]

On Sep 30, 9:30*am, "Peter Morris" <mrpmorri...@SP AMgmail.comwrot e:

System.Nullable is a ValueType. *It is a generic class, so the reference to
its value is not boxed, the value is also stored as a ValueType.

Hang on a sec. Just to be pedantic:

System.Nullable is a static class.
System.Nullable <Tis a value type - a generic *struct* (not class).

Personally I think it's a shame that System.Nullable (the class) even
exists, but there we go...

Jon

[Peter Morris]

>>
Hang on a sec. Just to be pedantic:

System.Nullable is a static class.
System.Nullable <Tis a value type - a generic *struct* (not class).
<<

You're pedantic, I'm too idle to write <T:-)

[Marc Gravell]

It makes a difference, though.

OK, maybe with List/List<Twe can guess - but Action & Action<Thave
very different meanings, for example. Likewise, IEnumerable and
IEnumerable<Tne ed disambiguating. If I'm feeling lazy, I'll use the C#
syntax - i.e. List<>, Dictionary<,etc .

Marc

[Peter Morris]

I'm not saying it doesn't matter. I am just saying that I often type a bit
vaguely when I think it's okay, and that the real meaning is easily inferred
based on what has been said previously. Personally I didn't know that
System.Nullable is a static class, I'm not pretending I knew, I've never
used it. I just meant System.Nullable <Tand was being lazy when I typed
:-)
Pete

[Peter Duniho]

On Tue, 30 Sep 2008 10:45:35 -0700, Peter Morris
<mr*********@sp amgmail.comwrot e:

I'm not saying it doesn't matter. I am just saying that I often type a
bit vaguely when I think it's okay, and that the real meaning is easily
inferred based on what has been said previously. Personally I didn't
know that System.Nullable is a static class, I'm not pretending I knew,
I've never used it. I just meant System.Nullable <Tand was being lazy
when I typed :-)

Yes, but you called it a class, when System.Nullable <Tis a struct.
There were two possible ways to interpret your statement, and neither
interpretation could be converted into a correct statement.

I empathize with the tempatation to be lazy, but programming is a
profession of intracacies and exactness. Heck, for that matter, most
professions are when done properly. But in programming it's particularly
important to be precise about what one says, because otherwise you may
wind up saying something completely different from what's true. As you
did in this particular case.

Barring being precise, one should at least be willing to accept a
correction without expressing defensiveness. :p

Pete

[Peter Morris]

Yes, but you called it a class, when System.Nullable <Tis a struct.

That's definitely a habit of mine. I don't bother defining anything as a
struct so I am still in the habit of calling everything a class, even after
all these years.

I empathize with the tempatation to be lazy, but programming is a
profession of intracacies and exactness.

Yeah, but then there is the consideration that my answer was essentially "It
*is* stored as a value type and not boxed". I don't really want to have to
check the padding text of my posts for 100% accuracy, and I don't suppose I
ever will.

wind up saying something completely different from what's true.

The essence of what I said was true. The value will not be boxed. The text
relevant to the question was accurate. The rest I paid less attention to.

Barring being precise, one should at least be willing to accept a
correction without expressing defensiveness. :p

Here I will be defensive. My reply to Jon was light hearted and I can't see
how it could possibly be perceived otherwise. On the whole I don't mind
being corrected at all, if I am wrong about something I like to know.
Pete