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. . If you are interested in nullable reference types, you can read several articles by my colleagues: " ", " ". Note Nullable Reference types in C# 8.0 and static analysis Nullable Reference will not protect you, and here is the proof 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. :) Well, let's do some thinking. Let's take a few main lines of thought that I think may arise. 1. Assume that int? is a reference type. Let's reason, that is a reference type. In this case, will be stored in , and it will also be stored in after assignment. A reference to an object will be stored in . It will also be stored in after assignment. As a result, will take and a non-null reference to the object as arguments, so... int? null a aObj b bObj Object.ReferenceEquals null That needs no saying, the answer is False! 2. Assume that int? is a value type. Or maybe you doubt that is a reference type? And you are sure of this, despite the expression? Well, let's go from the other side and start from the fact that is a value type. int? int? a = null int? In this case, the expression looks a bit strange, but let's assume that C# got some extra syntactic sugar. Turns out, stores an object. So does . When initializing and variables, objects stored in and will be boxed, resulting in different references being stored in and . So, in the end, takes references to different objects as arguments, therefore... int? a = null a b aObj bObj a b aObj bObj Object.ReferenceEquals That needs no saying, the answer is False! 3. We assume that here we use Nullable<T> . Let's say you didn't like the options above. Because you know perfectly well that there is no , but there is a value type , and in this case will be used. You also realize that and will actually have the same objects. With that, you remember that storing values in and will result in boxing. At long last, we'll get references to different objects. Since gets references to the different objects... int? Nullable<T> Nullable<int> a b aObj bObj Object.ReferenceEquals That needs no saying, the answer is False! 4. ;) For those who started from value types - if a suspicion crept into your mind about comparing links, you can view the documentation for at . 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. Object.ReferenceEquals docs.microsoft.com 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 , the ReferenceEquals method nevertheless returns false , as the following example shows. Here we could have ended the article, but the thing is that... the correct answer is . True Well, let's figure it out. Investigation There are two ways - simple and interesting. Simple way is . Open , 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. ;) int? Nullable<int> documentation on Nullable<T> Interesting way There won't be enough documentation on this path. It describes the behavior, but does not answer the question 'why'? What are actually and 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? int? null Let's start by analyzing the 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). int? int?, Nullable<T> 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. Let's look at the following code fragment: Although the initialization of these variables looks different in C#, the same IL code will be generated for all of them. As you can see, in C# everything is heartily flavored with syntactic sugar for our greater good. But in fact: is a value type. int? is the same as The IL code works with int? Nullable<int>. Nullable<int32> is the same as . In IL, this is compiled to an instruction that performs default initialization by the loaded address. int? aVal = null Nullable<int> aVal = new Nullable<int>() initobj Let's consider this code: We're done with the default initialization - we saw the related IL code above. What happens here when we want to initialize with the value 62? aVal Look at the IL code: Again, nothing complicated - the address pushes onto the evaluation stack, as well as the value 62. After the constructor with the signature is called. In other words, the following two statements will be completely identical: aVal Nullable<T>(T) You can also see this after checking out the IL code again: And what about the checks? What does this code represent? That's right, for better understanding, we will again refer to the corresponding IL code. As you may have guessed, there is actually no - all that happens is accessing the property. In other words, the same logic in C# can be written more explicitly in terms of the entities used, as follows. null Nullable<T>.HasValue IL code: Let's recap. Nullable value types are implemented using the type; Nullable<T> is actually a constructed type of the unbound generic value type ; int? Nullable<T> is the initialization of an object of type with the default value, no is actually present here; int? a = null Nullable<int> null - again, there is no , there is a call of the property. if (a == null) null Nullable<T>.HasValue The source code of the type can be viewed, for example, on GitHub in the dotnet/runtime repository - a . There's not much code there, so check it out just for kicks. From there, you can learn (or recall) the following facts. Nullable<T> direct link to the source code file For convenience, the type defines: Nullable<T> implicit conversion operator from to >; T Nullable<T explicit conversion operator from to . Nullable<T> T The main logic of work is implemented by two fields (and corresponding properties): - the value itself, the wrapper over which is ; T value Nullable<T> - the flag indicating "whether the wrapper contains a value". It's in quotation marks, since in fact always contains a value of type . bool hasValue Nullable<T> T Now that we've refreshed our memory about nullable value types, let's see what's going on with the boxing. Nullable<T> boxing Let me remind you that when boxing an object of a value type, a new object will be created on the heap. The following code snippet illustrates this behavior: The result of comparing references is expected to be . It is due to 2 boxing operations and creating of 2 objects whose references were stored in and false obj1 obj2 Now let's change to . int Nullable<int> The result is expectedly . false And now, instead of 62, we write the default value. Aaand... the result is unexpectedly . One might wonder that we have all the same 2 boxing operations, two created objects and references to two different objects, but the result is ! true true Yeah, it's probably sugar again, and something has changed at the IL code level! Let's see. Example N1. C# code: IL code: Example N2. C# code: IL code: Example N3. C# code: IL code: As we can see, in all cases boxing happens in the same way - values of local variables are pushed onto the evaluation stack ( instruction). After that the boxing itself occurs by calling the command, which specifies what type we will be boxing. ldloc box Next we refer to , see the description of the command, and find an interesting note regarding nullable types: Common Language Infrastructure specification box If typeTok is a value type, the box instruction converts val to its boxed form. ... If it is a nullable type, this is done by inspecting val's HasValue property; if it is false, a null reference is pushed onto the stack; otherwise, the result of boxing val's Value property is pushed onto the stack. This leads to several conclusions that dot the 'i': the state of the object is taken into account (the flag we discussed earlier is checked). If does not contain a value ( - ), the result of boxing is ; Nullable<T> HasValue Nullable<T> HasValue false null if contains a value ( - ), it is not a object that is boxed, but an instance of type that is stored in the field of type >; Nullable<T> HasValue true Nullable<T> T value Nullable<T specific logic for handling boxing is not implemented at the C# level or even at the IL level - it is implemented in the CLR. Nullable<T> Let's go back to the examples with that we touched upon above. Nullable<T> First: The state of the instance before the boxing: -> ; T int -> ; value 62 -> . hasValue true The value 62 is boxed twice. As we remember, in this case, instances of the type are boxed, not . Then 2 new objects are created, and 2 references to different objects are obtained, the result of their comparing is . int Nullable<int> false Second: The state of the instance before the boxing: -> ; T int -> (in this case, - a default value for ); value default 0 int -> . hasValue false Since is is , objects are not created. The boxing operation returns which is stored in variables and . Comparing these values is expected to return . hasValue false null obj1 obj2 true In the original example, which was at the very beginning of the article, exactly the same thing happens: For the sake of interest, let's look at the CoreCLR source code from the repository mentioned earlier. We are interested in the file , specifically, the x method with the logic we need: dotnet/runtime object.cpp Nullable::Bo Here we have everything we discussed earlier. If we don't store the value, we return : NULL Otherwise we initiate the boxing: Conclusion You're welcome to show the example from the beginning of the article to your colleagues and friends just for kicks. Will they give the correct answer and justify it? If not, share this article with them. If they do it - well, kudos to them! I hope it was a small but exciting adventure. :) Someone might have a question: how did we happen to dig that deep in this topic? We were writing a new diagnostic rule in related to working with arguments, one of which is represented by a value type. Suddenly it turned out that with there is an unexpected subtlety in the behavior when boxing. We looked at the IL code - there was nothing special about the . Checked out the CLI specification - and gotcha! The case promised to be rather exceptional and noteworthy, so here's the article right in front of you. P.S. PVS-Studio Object.ReferenceEquals Nullable<T> box By the way, recently, I have been spending more time on Twitter where I post some interesting code snippets and retweet some news in the .Net world and so on. Feel free to look through it and follow me if you want ( ). P.P.S. link to the profile Previously published at https://viva64.com/en/b/0772/

Microsoft

Twitter

Top 10 Bugs Found in C++ Projects in 2020

Fixing Code Errors in Amnesia: The Dark Descent

Too Long; Didn't Read

Make resilience your competitive advantage

The Programmer's Exam: Nullable Value Types

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Bugs from the 90's: The Code of Command and Conquer [Volume 2]

111 Stories To Learn About Csharp

130 Stories To Learn About Dotnet

C# 8.0 Indices and Ranges

3 Insanely Easy Changes You Can Make To Clean Up Your Code

Bugs from the 90's: The Code of Command and Conquer [Volume 2]

111 Stories To Learn About Csharp

130 Stories To Learn About Dotnet

C# 8.0 Indices and Ranges

3 Insanely Easy Changes You Can Make To Clean Up Your Code

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps