C# in Depth

What do you do when you just don’t have a value?1134.1 What do you do when you just don’t have a value?The C# and .NET designers don’t add features just for kicks. There has to be a real, significantproblem to be fixed before they’ll go as far as changing C# as a language or.NET at the platform level. In this case, the problem is best summed up in one of themost frequently asked questions in C# and .NET discussion groups:I need to set my DateTime 1 variable to null, but the compiler won’t let me.What should I do?It’s a question that comes up fairly naturally—a simple example might be in ane-commerce application where users are looking at their account history. If an orderhas been placed but not delivered, there may be a purchase date but no dispatchdate—so how would you represent that in a type that is meant to provide theorder details?The answer to the question is usually in two parts: first, why you can’t just use nullin the first place, and second, which options are available. Let’s look at the two parts separately—assumingthat the developer asking the question is using C# 1.4.1.1 Why value type variables can’t be nullAs we saw in chapter 2, the value of a reference type variable is a reference, and thevalue of a value type variable is the “real” value itself. A “normal” reference value issome way of getting at an object, but null acts as a special value that means “I don’trefer to any object.” If you want to think of references as being like URLs, null is (veryroughly speaking) the reference equivalent of about:blank. It’s represented as allzeroes in memory (which is why it’s the default value for all reference types—clearinga whole block of memory is cheap, so that’s the way objects are initialized), but it’s stillbasically stored in the same way as other references. There’s no “extra bit” hiddensomewhere for each reference type variable. That means we can’t use the “all zeroes”value for a “real” reference, but that’s OK—our memory is going to run out longbefore we have that many live objects anyway.The last sentence is the key to why null isn’t a valid value type value, though. Let’sconsider the byte type as a familiar one that is easy to think about. The value of a variableof type byte is stored in a single byte—it may be padded for alignment purposes,but the value itself is conceptually only made up of one byte. We’ve got to be able tostore the values 0–255 in that variable; otherwise it’s useless for reading arbitrarybinary data. So, with the 256 “normal” values and one null value, we’d have to copewith a total of 257 values, and there’s no way of squeezing that many values into a singlebyte. Now, the designers could have decided that every value type would have anextra flag bit somewhere determining whether a value was null or a “real” value, butthe memory usage implications are horrible, not to mention the fact that we’d have tocheck the flag every time we wanted to use the value. So in a nutshell, with value types1It’s almost always DateTime rather than any other value type. I’m not entirely sure why—it’s as if developersinherently understand why a byte shouldn’t be null, but feel that dates are more “inherently nullable.”Licensed to Rhona Hadida