Hello.
In this video, we're going to talk about Question 32, which is very popular during interviews.
Why does streaming behave like a value type, even though it is a reference type?
First of all, let's see this behavior in practice here.
I declared free methods.
The first one takes a value type.
The second takes a reference type and the third takes a string.
Each one of them is modifying the parameter.
It took, I say, input.
Now let's see how they are used for the first method.
I'm calling it with an integer, which is a value type.
The code will print this integer, then execute the method and then print the variable again.
The similar thing happens here.
But for reference types and also here first 3GHz.
Let's see how each of those types will behave.
First, the very types when a valley type is passed as a parameter tormented, a copy of the value is
created.
That's why even if the parameter has been incremented in the market, this variable is not changed because
a copy of it has been passed to a method, and it's the copy that has been increment it.
But this is not the case for reference types.
Reference types are passed by reference.
So the object I'm modifying in the method is exactly the same object that I passed as a parameter.
No copy is created, and that's why the modification is visible after the method finishes.
And now the string.
I'm also putting it as a parameter to our method and then modifying it inside.
But as you can see, the variable I printed after the method finishes, it's not changed.
In other words, string behaves like a value type.
But here is the plot twist.
String is a reference type in c sharp.
So what is going on to understand it, we must first realize that under the hood, string isn't all
right, of course, as we learned in the what is in our lecture.
Roles are collections of fixed size.
Once an error is created, its size never changes.
If you want to add an element to an array, we must declare a new, bigger array.
Copy the old arrow to it and set the value under the last index to the new element.
And that's exactly what happens when we modify a string.
This modification is not really changing the original string.
It is creating a new string, which then gets assigned to the variable.
In this case, the new string contains the original string, with one added at the end.
This means strings in C-sharp are immutable.
A string object is never modified, even if it seems like it.
A new object is actually created under the hood.
As we've already seen, when passed as a parameter formatted, the string behaves like a value type.
But this is not the end of similarity of strings to value types.
Also, it's equality operator is overloaded, so it compares strings by value, not by reference.
Let's see this in practice.
Least is a reference type.
So even if those two lists seem the same.
The exchange operator returns false for them because the references are different.
Those two strings are also reference types, but in their case, the quality operator returns true.
Strings are compiled by value, even though they are reference types.
Technical reasons aside, it is actually desired for strings to behave more like value types than reference
types.
I think most programmers would be surprised if for those two strings, that equate operator would return
false as it should for regular reference types.
Also, it would be pretty challenging if the modification of a string in mattered to it.
It was passed as a parameter would affect the original string.
In general, people tend to think of strings in a similar way.
They think of a value types and learning to use them as other reference types would most likely make
C-sharp quite disliked in the programming community.
You may wonder seems string behaves like a violin type.
Why isn't it one?
Maybe another design.
Then using the array of characters would be possible, and string could be a value type like numbers
or datetime.
Well, the answer is, as so often related to performance value types are stored on the stock, which
has a limited size.
It's one megabyte for 32 bit processes and four megabytes for 64 bits.
Process strings can be quite huge, and they could simply not fit on the stack.
They are stored on the heap instead, along with other reference sticks.
One more thing before we wrap up because strings are immutable, we have multiple strings of the same
value we can use.
The optimization, called interlink interning, means that if multiple string variables hold strings
that are known to be equal, the runtime actually points the reference to a single string object, thereby
saving memory.
This optimization wouldn't work if strings were immutable, because then changing one string variable
would have unpredictable results on other string variables.
Let's summarize String is a reference type with the value type semantics.
All strings are immutable, which means when they seem to be modified, actually, a new altered string
is created.
String has voted semantics as this is more convenient for developers, but it can be a value type because
string objects can be large and vocal types are stored on the stack, which has unlimited size because
this copy and other way of modifying strings can be performance costly.
It is recommended to use the string builder class when building strings incrementally.
We'll learn more about it in the next lecture.
During the interview, you can hear questions like What is turning off strings in turning means that
if multiple strings are known to be equal, the runtime can just use a single string, thereby saving
memory.
This optimization wouldn't work if strings were mutable, because then changing one string would have
unpredictable results on other strings.
What is the size of the stock in megabytes?
It's one gigabyte for 32 bit processors and four megabytes for 64 bit processors.
What is the underlying data structure for strings?
It's an array, of course.
Arrays by definition have fixed size, which is a reason why strings are immutable.
We couldn't modify a string by adding new characters to it because the new characters wouldn't fit in
the underlying array.
All right, let's eat in this lecture.
Thanks for watching and see you in the next one one.
We will continue talking about strings.