Reference Types v. Value Types
-
the .NET String class is a reference type, correct? Why then must I add the ref keyword to a string argument if I want its value to be updated in the called function? No other reference type behaves this way, correct? :confused: UPDATE: I just realized what's going on. Strings are immutable so when you pass a string with the ref keyword, it's the original reference to the string that is being updated with the new string. Without the ref keyword, the called function gets its own reference to the string, and if changes are made, then it's the function's reference that is updated, not the original reference. :)
The difficult we do right away... ...the impossible takes slightly longer.
-
the .NET String class is a reference type, correct? Why then must I add the ref keyword to a string argument if I want its value to be updated in the called function? No other reference type behaves this way, correct? :confused: UPDATE: I just realized what's going on. Strings are immutable so when you pass a string with the ref keyword, it's the original reference to the string that is being updated with the new string. Without the ref keyword, the called function gets its own reference to the string, and if changes are made, then it's the function's reference that is updated, not the original reference. :)
The difficult we do right away... ...the impossible takes slightly longer.
Dat's de bunny!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
the .NET String class is a reference type, correct? Why then must I add the ref keyword to a string argument if I want its value to be updated in the called function? No other reference type behaves this way, correct? :confused: UPDATE: I just realized what's going on. Strings are immutable so when you pass a string with the ref keyword, it's the original reference to the string that is being updated with the new string. Without the ref keyword, the called function gets its own reference to the string, and if changes are made, then it's the function's reference that is updated, not the original reference. :)
The difficult we do right away... ...the impossible takes slightly longer.
I look at 'string as a chimera: a reference type (heap allocated [1], a class, no fixed allocation size, can be 'null) with value type semantics (immutability). Adding to the inter-species flavor is that == will compare content, not references. Under the hood a Char[]. [1] Eric Lippert's blogs illuminate the complexity of strings and memory allocation in .NET:
Quote:
"It is simply false that the choice of whether to use the stack or the heap has anything fundamentally to do with the type of the thing being stored. The truth is: the choice of allocation mechanism has to do only with the known required lifetime of the storage."
[^] [^] you'll have to look for these since @@^77!! MSDN has archived them: http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation- detail.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/05/04/the-stack-is-an-implementation- detail-part-two.aspx http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
-
I look at 'string as a chimera: a reference type (heap allocated [1], a class, no fixed allocation size, can be 'null) with value type semantics (immutability). Adding to the inter-species flavor is that == will compare content, not references. Under the hood a Char[]. [1] Eric Lippert's blogs illuminate the complexity of strings and memory allocation in .NET:
Quote:
"It is simply false that the choice of whether to use the stack or the heap has anything fundamentally to do with the type of the thing being stored. The truth is: the choice of allocation mechanism has to do only with the known required lifetime of the storage."
[^] [^] you'll have to look for these since @@^77!! MSDN has archived them: http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation- detail.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/05/04/the-stack-is-an-implementation- detail-part-two.aspx http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
Thanks Bill! That's a very useful post.
The difficult we do right away... ...the impossible takes slightly longer.
-
Thanks Bill! That's a very useful post.
The difficult we do right away... ...the impossible takes slightly longer.
here's a Lippert blog I find very relevant: Strings, immutability and persistence[^] i like to confuse my students :) by asking them: if a Point is a ValueType (immutable), why can you set its X/Y properties directly without creating a new copy. To (maybe) get across the idea that immutable and passed by value are not necessarily synonymous.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
-
the .NET String class is a reference type, correct? Why then must I add the ref keyword to a string argument if I want its value to be updated in the called function? No other reference type behaves this way, correct? :confused: UPDATE: I just realized what's going on. Strings are immutable so when you pass a string with the ref keyword, it's the original reference to the string that is being updated with the new string. Without the ref keyword, the called function gets its own reference to the string, and if changes are made, then it's the function's reference that is updated, not the original reference. :)
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
the .NET String class is a reference type, correct?
No, it's a value type. Even though strings are heap-based, .net does smoke-and-mirrors behind the scenes to ensure strings behave like value types. Probably to make the language easier to use as strings are very common. The downside is that it can lead to poor performance if you're not aware of the caveats.
-
Richard Andrew x64 wrote:
the .NET String class is a reference type, correct?
No, it's a value type. Even though strings are heap-based, .net does smoke-and-mirrors behind the scenes to ensure strings behave like value types. Probably to make the language easier to use as strings are very common. The downside is that it can lead to poor performance if you're not aware of the caveats.
F-ES Sitecore wrote:
No, it's a value type.
No, it's an immutable reference type. There's not much in the way of smoke-and-mirrors involved; you can easily create your own immutable reference type to get the same behaviour. If
stringwas really a value type, you wouldn't sensibly be able to have a value type with a string member. The entire string would be stored "in-line" within that struct, and you'd end up with stack overflow exceptions everywhere. It's probably better to say that in some circumstances it's easier to think ofstringas a value type, even though it isn't. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
F-ES Sitecore wrote:
No, it's a value type.
No, it's an immutable reference type. There's not much in the way of smoke-and-mirrors involved; you can easily create your own immutable reference type to get the same behaviour. If
stringwas really a value type, you wouldn't sensibly be able to have a value type with a string member. The entire string would be stored "in-line" within that struct, and you'd end up with stack overflow exceptions everywhere. It's probably better to say that in some circumstances it's easier to think ofstringas a value type, even though it isn't. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
it's easier to think of
stringas a value type, even though it isn'tWhich is what I was saying.
