{"id":416218,"date":"2024-06-30T00:49:37","date_gmt":"2024-06-30T00:49:37","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=416218"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=416218","title":{"rendered":"Check how you remember nullable value types. Let’s peek under the hood<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n
\"image1.png\"<\/div>\n

Recently nullable reference types have become trendy. Meanwhile, the good old nullable value types are still here and actively used. How well do you remember the nuances of working with them? Let’s jog your memory or test your knowledge by reading this article. Examples of C# and IL code, references to the CLI specification, and CoreCLR code are provided. Let’s start with an interesting case.
<\/a>
Note<\/b>. If you are interested in nullable reference types, you can read several articles by my colleagues: «Nullable Reference types in C# 8.0 and static analysis<\/a>«, «Nullable Reference will not protect you, and here is the proof<\/a>«.<\/p>\n

Take a look at the sample code below and answer what will be output to the console. And, just as importantly, why. Just let’s agree right away that you will answer as it is: without compiler hints, documentation, reading literature, or anything like that. \ud83d\ude42<\/p>\n

static void NullableTest() {   int? a = null;   object aObj = a;    int? b = new int?();   object bObj = b;    Console.WriteLine(Object.ReferenceEquals(aObj, bObj)); \/\/ True or False? }<\/code><\/pre>\n
  <\/p>\n
\"image2.png\"<\/div>\n
  Well, let’s do some thinking. Let’s take a few main lines of thought that I think may arise.<\/p>\n
  1. Assume that int? <\/i>is a reference type.<\/b><\/p>\n
  Let’s reason, that int? <\/i>is a reference type. In this case, null<\/i> will be stored in a<\/i>, and it will also be stored in aObj<\/i> after assignment. A reference to an object will be stored in b<\/i>. It will also be stored in bObj<\/i> after assignment. As a result, Object.ReferenceEquals<\/i> will take null<\/i> and a non-null reference to the object as arguments, so\u2026<\/p>\n
  That needs no saying, the answer is False!<\/b><\/p>\n
  2. Assume that int?<\/i> is a value type.<\/b><\/p>\n
  Or maybe you doubt that int?<\/i> is a reference type? And you are sure of this, despite the int? a = null <\/i>expression? Well, let’s go from the other side and start from the fact that int?<\/i> is a value type.<\/p>\n
  In this case, the expression int? a = null<\/i> looks a bit strange, but let’s assume that C# got some extra syntactic sugar. Turns out, a<\/i> stores an object. So does b<\/i>. When initializing aObj<\/i> and bObj<\/i> variables, objects stored in a<\/i> and b<\/i> will be boxed, resulting in different references being stored in aObj<\/i> and bObj<\/i>. So, in the end, Object.ReferenceEquals<\/i> takes references to different objects as arguments, therefore\u2026<\/p>\n
  That needs no saying, the answer is False!<\/b><\/p>\n
  3. We assume that here we use Nullable<T><\/i>.<\/b><\/p>\n
  Let’s say you didn’t like the options above. Because you know perfectly well that there is no int?<\/i>, but there is a value type Nullable<T><\/i>, and in this case Nullable<int><\/i> will be used. You also realize that a<\/i> and b<\/i> will actually have the same objects. With that, you remember that storing values in aObj<\/i> and bObj<\/i> will result in boxing. At long last, we’ll get references to different objects. Since Object.ReferenceEquals<\/i> gets references to the different objects\u2026<\/p>\n
  That needs no saying, the answer is False!<\/b><\/p>\n
  4. \ud83d\ude09<\/b><\/p>\n
  For those who started from value types \u2014 if a suspicion crept into your mind about comparing links, you can view the documentation for Object.ReferenceEquals<\/i> at docs.microsoft.com<\/a>. In particular, it also touches on the topic of value types and boxing\/unboxing. Except for the fact that it describes the case, when instances of value types are passed directly to the method, whereas we made the boxing separately, but the main point is the same.<\/p>\n
  When comparing value types, if objA and objB are value types, they are boxed before they are passed to the ReferenceEquals method. This means that if both objA and objB represent the same instance of a value type<\/b>, the ReferenceEquals method nevertheless returns false<\/b>, as the following example shows.<\/i><\/p>\n
  Here we could have ended the article, but the thing is that\u2026 the correct answer is True<\/b>.<\/p>\n
  Well, let’s figure it out.<\/p>\n
Investigation<\/h2>\n
  There are two ways \u2014 simple and interesting.<\/p>\n
Simple way<\/h3>\n
  int?<\/i> is Nullable<int><\/i>. Open documentation on Nullable<T><\/i><\/a>, where we look at the section «Boxing and Unboxing». Well, that’s all, see the behavior description. But if you want more details, welcome to the interesting path. \ud83d\ude09<\/p>\n
Interesting way<\/h3>\n
  There won’t be enough documentation on this path. It describes the behavior, but does not answer the question ‘why’?<\/p>\n
  What are actually int?<\/i> and null<\/i> in the given context? Why does it work like this? Are there different commands used in the IL code or not? Is behavior different at the CLR level? Is it another kind of magic?<\/p>\n
  Let’s start by analyzing the int?<\/i> entity to recall the basics, and gradually get to the initial case analysis. Since C# is a rather «sugary» language, we will sometimes refer to the IL code to get to the bottom of things (yes, C# documentation is not our cup of tea today).<\/p>\n
int?, Nullable<T><\/h4>\n
  Here we will look at the basics of nullable value types in general: what they are, what they are compiled into in IL, etc. The answer to the question from the case at the very beginning of the article is discussed in the next section.<\/p>\n
  Let’s look at the following code fragment:<\/p>\n
int? aVal = null; int? bVal = new int?(); Nullable<int> cVal = null; Nullable<int> dVal = new Nullable<int>();<\/code><\/pre>\n
  Although the initialization of these variables looks different in C#, the same IL code will be generated for all of them.<\/p>\n
.locals init (valuetype [System.Runtime]System.Nullable`1<int32> V_0,               valuetype [System.Runtime]System.Nullable`1<int32> V_1,               valuetype [System.Runtime]System.Nullable`1<int32> V_2,               valuetype [System.Runtime]System.Nullable`1<int32> V_3)  \/\/ aVal ldloca.s V_0 initobj  valuetype [System.Runtime]System.Nullable`1<int32>  \/\/ bVal ldloca.s V_1 initobj  valuetype [System.Runtime]System.Nullable`1<int32>  \/\/ cVal ldloca.s V_2 initobj  valuetype [System.Runtime]System.Nullable`1<int32>  \/\/ dVal ldloca.s V_3 initobj  valuetype [System.Runtime]System.Nullable`1<int32><\/code><\/pre>\n
  As you can see, in C# everything is heartily flavored with syntactic sugar for our greater good. But in fact:<\/p>\n