Nullable types in C# - Heap or Stack?

tags:

c#
nullable

views:

105

answers:

+1 Q:

Nullable types in C# - Heap or Stack?

Possible Duplicate:
Where in memory are stored nullable types?

A very basic question on Nullable types - where do the nullable values get stored - Heap or Stack?

I would believe it should be stored in Stack as Nullable stack is a struct. How does Null value get stored in a stack?

Nullable is applicable for value types so must be on Stack.

saurabh 2010-09-28 09:47:22

Can you explain your reasoning here? (Your answer is wrong; I am interested in learning how people come to have incorrect beliefs about programming languages so that we can design better languages, documentation, and so on, that does not mislead people into having incorrect beliefs.)

Eric Lippert 2010-09-28 14:19:55

Which part r you talking about ? Is it Nullable is applicable to value types or must be on stack?

saurabh 2010-09-28 14:36:28

Both. First, the fact that Nullable<T> is constrained to value types is irrelevant; I can make a reference type Foo<T> where T is constrained to value types and it need not go on the stack. Second, value types don't "go on the stack". Value types go on the stack sometimes and onto the heap sometimes, depending on their lifetime. What I'm interested in is how you came by these beliefs.

Eric Lippert 2010-09-28 14:39:07

so why null keyword is there in c#? why you guys don't make value types to accept null reference? Why i am saying this , i don't need to remember Nullable thing if simply i can assign null to an int. int i = null;

saurabh 2010-09-28 14:43:15

i am reading your answer here : http://stackoverflow.com/questions/2865604/where-in-memory-are-stored-nullable-types

saurabh 2010-09-28 14:46:48

Data types are separated into value types and reference types. Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated. i took this from MSDN site http://msdn.microsoft.com/en-us/library/system.valuetype(v=VS.71).aspx under Remarks

saurabh 2010-09-28 15:10:09

@saurabh: "why not make value types to accept a null reference"? The question answers itself: **value** types cannot be a null **reference** because *value* types are not *reference* types. Nullable<T> makes a null *value*, not a null *reference*. Now, that said, I sincerely wish that the v1 CLR type system had supported nullable value types, non-nullable value types, nullable reference types and non-nullable reference types from day one. When you next design a type system from scratch I encourage you to learn from our experience. The best mistakes to learn from are other people's.

Eric Lippert 2010-09-29 14:17:17

@saurabh: The MSDN article you reference I believe could be more clear. But it does basically say "value types are allocated on the stack **except when they are not allocated on the stack**." It does *not* say what you said, which is that they *must* go on the stack; the documentation says that they *can* go on the stack.

Eric Lippert 2010-09-29 14:20:49

Eric, I don't think documentation really reads anything like what you wrote. It says " Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated". I don't know how you read it as 'except when they are not allocated on the stack'. Also not sure what 'allocated inline in a structure' means. When I started .NET programming, everything I read talked about how Value Types are allocated on stack. It was after reading Jon Skeet's book and your blog and numerous answers on StackOverflow that I realized true meaning of Value Types.

SolutionYogi 2010-09-29 15:36:10

@Eric: When you say "I sincerely wish that the v1 CLR type system had supported nullable value types, non-nullable value types, nullable reference types and non-nullable reference types from day one." what would be the advantage of that? I remember watching a video where Anders was saying something like "if everything was nullable by default, it would offer a performance advantage" or something. Is this true or is this the reason you wish for that? I am just curious what would offer the best advantage/performance in a type system that you can design/work on?

Joan Venge 2010-09-29 16:30:13

@Joan: Couple reasons. First, it would have been simply "cleaner" to have "copy-by-value-or-reference" orthogonal to "this value can be missing". The situation we have now is a bit of a mess. It would have been nice to simply say for any type S, there's another type S? which is the nullable version of that type. So there would be "string" and "string?" and the former could not be null. Second, adding nullable value types post facto was not too hard, but adding non-nullable reference types post facto has proven to be quite difficult. It's easier to add these at the beginning.

Eric Lippert 2010-09-29 19:51:37

@Eric: Thanks for replying. So are there non-nullable reference types in .NET now? I see what you mean now though. Seeing these before would have made things easier for you. But is there a performance advantage to this? Or having everything as non-nullable by default? If you want I could find the video where Anders mentioned this. I think it was a video where he was talking about Spec#, saying they made a mistake in C# by not having everything as non-nullable, so everything would have to have a value and the null would be implemented differently? It's very interesting IMO.

Joan Venge 2010-09-29 20:11:11

@Joan: Indeed, Spec#, a special "research only" version of C# does support non-nullable reference types. They are not in the framework proper or in the production version of C#. The advantage is not in performance; all you save is a null check that takes less than a nanosecond. The advantage is in the increased robustness and code legibility you get in a world where you know that *every* reference is to a valid storage location unless specifically marked as nullable. When you code review "Foo().Bar().Blah()" you don't have to ask "what if Bar() returns null?" if the type system forbids it.

Eric Lippert 2010-09-29 22:59:55

@Eric: Thanks Eric. That's what I was wondering. So do you know why this wasn't in C# 1.0? Is it because this wasn't a very straightforward thing to come up when there was no type system? Is it like C# has nullable reference types which require lots of null checking for a minority of scenarios where the majority actually requires uses of non-nullable reference types?

Joan Venge 2010-09-29 23:12:41

Here is a link which might help you understand the Nullable types -

http://msdn.microsoft.com/en-us/library/b3h38hb0.aspx

Sachin Shanbhag 2010-09-28 09:48:57

ansaurus

tags:

views:

answers:

Nullable types in C# - Heap or Stack?

related questions