1
00:00:06,450 --> 00:00:06,800
Hello.

2
00:00:08,220 --> 00:00:14,520
In this video, we're going to talk about Question 32, which is very popular during interviews.

3
00:00:14,970 --> 00:00:20,700
Why does streaming behave like a value type, even though it is a reference type?

4
00:00:21,210 --> 00:00:25,310
First of all, let's see this behavior in practice here.

5
00:00:25,320 --> 00:00:26,970
I declared free methods.

6
00:00:27,480 --> 00:00:29,730
The first one takes a value type.

7
00:00:30,000 --> 00:00:34,530
The second takes a reference type and the third takes a string.

8
00:00:35,040 --> 00:00:37,770
Each one of them is modifying the parameter.

9
00:00:37,830 --> 00:00:39,360
It took, I say, input.

10
00:00:39,870 --> 00:00:44,250
Now let's see how they are used for the first method.

11
00:00:44,460 --> 00:00:47,790
I'm calling it with an integer, which is a value type.

12
00:00:48,210 --> 00:00:54,870
The code will print this integer, then execute the method and then print the variable again.

13
00:00:55,560 --> 00:00:57,510
The similar thing happens here.

14
00:00:57,540 --> 00:01:02,190
But for reference types and also here first 3GHz.

15
00:01:02,850 --> 00:01:05,670
Let's see how each of those types will behave.

16
00:01:07,690 --> 00:01:14,770
First, the very types when a valley type is passed as a parameter tormented, a copy of the value is

17
00:01:14,770 --> 00:01:15,580
created.

18
00:01:15,940 --> 00:01:22,870
That's why even if the parameter has been incremented in the market, this variable is not changed because

19
00:01:22,870 --> 00:01:28,300
a copy of it has been passed to a method, and it's the copy that has been increment it.

20
00:01:28,780 --> 00:01:31,330
But this is not the case for reference types.

21
00:01:31,600 --> 00:01:34,660
Reference types are passed by reference.

22
00:01:34,840 --> 00:01:41,530
So the object I'm modifying in the method is exactly the same object that I passed as a parameter.

23
00:01:42,130 --> 00:01:48,470
No copy is created, and that's why the modification is visible after the method finishes.

24
00:01:49,120 --> 00:01:50,740
And now the string.

25
00:01:51,160 --> 00:01:56,260
I'm also putting it as a parameter to our method and then modifying it inside.

26
00:01:56,650 --> 00:02:02,110
But as you can see, the variable I printed after the method finishes, it's not changed.

27
00:02:02,380 --> 00:02:05,920
In other words, string behaves like a value type.

28
00:02:06,250 --> 00:02:07,660
But here is the plot twist.

29
00:02:08,110 --> 00:02:10,990
String is a reference type in c sharp.

30
00:02:11,230 --> 00:02:18,910
So what is going on to understand it, we must first realize that under the hood, string isn't all

31
00:02:18,910 --> 00:02:23,560
right, of course, as we learned in the what is in our lecture.

32
00:02:23,850 --> 00:02:26,710
Roles are collections of fixed size.

33
00:02:27,010 --> 00:02:30,910
Once an error is created, its size never changes.

34
00:02:31,420 --> 00:02:36,850
If you want to add an element to an array, we must declare a new, bigger array.

35
00:02:36,940 --> 00:02:43,030
Copy the old arrow to it and set the value under the last index to the new element.

36
00:02:43,300 --> 00:02:46,870
And that's exactly what happens when we modify a string.

37
00:02:53,680 --> 00:02:57,550
This modification is not really changing the original string.

38
00:02:57,880 --> 00:03:02,470
It is creating a new string, which then gets assigned to the variable.

39
00:03:02,830 --> 00:03:09,220
In this case, the new string contains the original string, with one added at the end.

40
00:03:09,790 --> 00:03:13,210
This means strings in C-sharp are immutable.

41
00:03:13,570 --> 00:03:18,100
A string object is never modified, even if it seems like it.

42
00:03:18,340 --> 00:03:21,550
A new object is actually created under the hood.

43
00:03:22,000 --> 00:03:28,480
As we've already seen, when passed as a parameter formatted, the string behaves like a value type.

44
00:03:28,900 --> 00:03:33,340
But this is not the end of similarity of strings to value types.

45
00:03:33,980 --> 00:03:41,080
Also, it's equality operator is overloaded, so it compares strings by value, not by reference.

46
00:03:41,620 --> 00:03:43,240
Let's see this in practice.

47
00:03:44,720 --> 00:03:46,490
Least is a reference type.

48
00:03:46,760 --> 00:03:49,550
So even if those two lists seem the same.

49
00:03:49,850 --> 00:03:55,700
The exchange operator returns false for them because the references are different.

50
00:03:56,180 --> 00:04:03,230
Those two strings are also reference types, but in their case, the quality operator returns true.

51
00:04:03,680 --> 00:04:07,820
Strings are compiled by value, even though they are reference types.

52
00:04:08,510 --> 00:04:15,710
Technical reasons aside, it is actually desired for strings to behave more like value types than reference

53
00:04:15,710 --> 00:04:16,310
types.

54
00:04:16,760 --> 00:04:23,330
I think most programmers would be surprised if for those two strings, that equate operator would return

55
00:04:23,330 --> 00:04:27,050
false as it should for regular reference types.

56
00:04:27,530 --> 00:04:33,200
Also, it would be pretty challenging if the modification of a string in mattered to it.

57
00:04:33,200 --> 00:04:37,190
It was passed as a parameter would affect the original string.

58
00:04:37,610 --> 00:04:41,750
In general, people tend to think of strings in a similar way.

59
00:04:41,750 --> 00:04:48,380
They think of a value types and learning to use them as other reference types would most likely make

60
00:04:48,380 --> 00:04:51,710
C-sharp quite disliked in the programming community.

61
00:04:52,220 --> 00:04:56,000
You may wonder seems string behaves like a violin type.

62
00:04:56,030 --> 00:04:57,380
Why isn't it one?

63
00:04:57,740 --> 00:04:59,180
Maybe another design.

64
00:04:59,180 --> 00:05:05,570
Then using the array of characters would be possible, and string could be a value type like numbers

65
00:05:05,570 --> 00:05:06,560
or datetime.

66
00:05:07,010 --> 00:05:15,380
Well, the answer is, as so often related to performance value types are stored on the stock, which

67
00:05:15,380 --> 00:05:16,670
has a limited size.

68
00:05:17,030 --> 00:05:23,240
It's one megabyte for 32 bit processes and four megabytes for 64 bits.

69
00:05:23,240 --> 00:05:28,970
Process strings can be quite huge, and they could simply not fit on the stack.

70
00:05:29,300 --> 00:05:33,680
They are stored on the heap instead, along with other reference sticks.

71
00:05:34,070 --> 00:05:41,120
One more thing before we wrap up because strings are immutable, we have multiple strings of the same

72
00:05:41,120 --> 00:05:42,560
value we can use.

73
00:05:42,560 --> 00:05:49,880
The optimization, called interlink interning, means that if multiple string variables hold strings

74
00:05:49,880 --> 00:05:57,140
that are known to be equal, the runtime actually points the reference to a single string object, thereby

75
00:05:57,140 --> 00:05:58,160
saving memory.

76
00:05:58,580 --> 00:06:05,060
This optimization wouldn't work if strings were immutable, because then changing one string variable

77
00:06:05,060 --> 00:06:08,930
would have unpredictable results on other string variables.

78
00:06:09,500 --> 00:06:14,560
Let's summarize String is a reference type with the value type semantics.

79
00:06:14,990 --> 00:06:21,620
All strings are immutable, which means when they seem to be modified, actually, a new altered string

80
00:06:21,620 --> 00:06:22,580
is created.

81
00:06:22,970 --> 00:06:30,320
String has voted semantics as this is more convenient for developers, but it can be a value type because

82
00:06:30,320 --> 00:06:37,820
string objects can be large and vocal types are stored on the stack, which has unlimited size because

83
00:06:37,820 --> 00:06:43,340
this copy and other way of modifying strings can be performance costly.

84
00:06:43,460 --> 00:06:49,220
It is recommended to use the string builder class when building strings incrementally.

85
00:06:49,610 --> 00:06:52,460
We'll learn more about it in the next lecture.

86
00:06:53,240 --> 00:07:01,250
During the interview, you can hear questions like What is turning off strings in turning means that

87
00:07:01,250 --> 00:07:08,210
if multiple strings are known to be equal, the runtime can just use a single string, thereby saving

88
00:07:08,210 --> 00:07:08,810
memory.

89
00:07:09,170 --> 00:07:16,040
This optimization wouldn't work if strings were mutable, because then changing one string would have

90
00:07:16,040 --> 00:07:18,770
unpredictable results on other strings.

91
00:07:19,430 --> 00:07:22,520
What is the size of the stock in megabytes?

92
00:07:22,970 --> 00:07:29,870
It's one gigabyte for 32 bit processors and four megabytes for 64 bit processors.

93
00:07:30,590 --> 00:07:33,950
What is the underlying data structure for strings?

94
00:07:34,340 --> 00:07:35,990
It's an array, of course.

95
00:07:36,380 --> 00:07:42,350
Arrays by definition have fixed size, which is a reason why strings are immutable.

96
00:07:42,800 --> 00:07:49,910
We couldn't modify a string by adding new characters to it because the new characters wouldn't fit in

97
00:07:49,910 --> 00:07:51,200
the underlying array.

98
00:07:51,800 --> 00:07:54,290
All right, let's eat in this lecture.

99
00:07:54,500 --> 00:07:57,440
Thanks for watching and see you in the next one one.

100
00:07:57,440 --> 00:07:59,780
We will continue talking about strings.