WEBVTT 00:00.490 --> 00:07.800 Welcome, as you know, string values are only or in other words, immutable values in this lecture, 00:07.840 --> 00:10.120 you're going to learn why they are like so. 00:10.540 --> 00:12.020 All right, let's get started. 00:13.210 --> 00:17.930 Let's take a look at this string literal, you learned that a string value is a slice. 00:18.490 --> 00:22.510 Remember, a slice is a simple data structure that points to a bank. 00:22.510 --> 00:23.020 Incorrect. 00:23.960 --> 00:31.000 So if a street value is also a slice, then it should also point to a back injury, right? 00:31.430 --> 00:32.690 Yes, that's right. 00:33.470 --> 00:35.100 Let's take a look at behind the curtain. 00:35.960 --> 00:39.920 A street value is a tiny data structure called the string Heather. 00:41.130 --> 00:43.260 Here the street value is hello. 00:43.920 --> 00:46.740 It has five bytes, so its length is five. 00:47.100 --> 00:52.980 Whenever you call the land function on a string value, it returns the length of the string just by 00:52.980 --> 00:59.610 looking at this field inside the string hattar so it doesn't calculate the length of a string each time 00:59.610 --> 01:01.140 you want to learn its length. 01:01.560 --> 01:03.720 The third field is the capacity field. 01:04.080 --> 01:09.570 Remember the capacity controls how much a slice can grow, but a string value cannot grow. 01:09.780 --> 01:10.770 It is read only. 01:11.070 --> 01:13.280 So does it really need to have a capacity? 01:13.710 --> 01:14.440 Of course not. 01:14.550 --> 01:15.240 Let's with. 01:16.470 --> 01:23.400 This is what a strong leader looks like, it describes where a street value starts and ends in computer 01:23.400 --> 01:23.880 memory. 01:24.210 --> 01:26.220 It works just like a slice header. 01:26.760 --> 01:27.920 So far, so good. 01:28.080 --> 01:30.330 But I didn't answer the first question. 01:30.510 --> 01:33.030 Why is a street value read only? 01:33.600 --> 01:37.230 Let's say I have to string values and they are equal. 01:38.320 --> 01:42.490 They are pointers point to the same elements in the same back in Gary. 01:44.740 --> 01:51.870 They are Langguth, are also the same as you can see, Gore shares the same back, Gary among them. 01:52.420 --> 01:55.480 It does so because strings are used a lot. 01:55.720 --> 01:59.910 So by doing this, Gore needs to allocate a fewer number of backing. 02:01.000 --> 02:03.800 It aims to keep the memory usage low. 02:04.090 --> 02:05.710 It's all about the efficiency. 02:07.110 --> 02:14.520 Let me show you one more example, let's say I sliced this string value lachsa so its pointer becomes 02:14.520 --> 02:18.810 sixty just three bytes away from the start of the Helo's string. 02:19.260 --> 02:24.570 Instead of creating a new back injury, the new string value uses the same back in. 02:24.570 --> 02:24.950 Correct. 02:25.440 --> 02:32.370 So you can say that God creates a lot of back injuries inside the memory as your program runs, then 02:32.370 --> 02:35.220 it tries to share them among the string headers. 02:35.760 --> 02:40.800 That is why the strings are read only if they were not read, only changing. 02:40.800 --> 02:43.350 Only one of them would break your program. 02:43.350 --> 02:49.330 And it would lead to very hard to fix problems because strings share the same backing arrays. 02:50.100 --> 02:52.020 Let me show you one more example. 02:55.000 --> 03:01.510 Let's say I need to convert the strength to a bad slice here, the conversion creates a new bite slice. 03:01.960 --> 03:03.780 The slice needs a back injury. 03:04.150 --> 03:11.380 However, unlike a drink, a slice is not read-only, so it cannot use the same backing of the string 03:11.380 --> 03:11.740 value. 03:12.370 --> 03:18.900 Because of that, go allocates a new back injury for the slice and it copies the first back, carries 03:18.910 --> 03:20.800 data to the new back injury. 03:21.430 --> 03:28.150 As you know, whenever something is copied or allocated, it will consume computer resources such as 03:28.150 --> 03:30.200 memory, CPU and so on. 03:30.820 --> 03:35.080 So it should be your goal to reduce unnecessary allocations and copies. 03:36.000 --> 03:42.870 Anyway, after creating a new back injury and copying the previous arrest data into it, Gore sets the 03:42.870 --> 03:50.220 slicers pointer to the newly created back injury and it determines that the length of the slice is five 03:50.220 --> 03:53.550 bytes because there are five bytes in the string. 03:54.500 --> 03:59.660 By the way, when you convert the strength to a bite slice, its capacity can be anything. 04:00.230 --> 04:05.270 I mean, its capacity doesn't have to be equal to the length of the converted shrink. 04:06.020 --> 04:08.810 For example, here the capacity becomes 10. 04:09.470 --> 04:13.520 This number may change depending on the go runtime that you are using. 04:14.280 --> 04:18.260 OK, now you are learnt how the strings work behind the scenes. 04:18.710 --> 04:24.020 Now I'm going to show you some concrete examples about the inner workings of strings in the coding, 04:24.020 --> 04:24.410 Ed.. 04:24.680 --> 04:25.890 All right, let's get started. 04:26.840 --> 04:33.950 Here I created some court previously, this is what a sprinkler looks like in the real go code, as 04:33.950 --> 04:40.730 I showed you, it has a pointer to the back injury and it determines where a string value starts and 04:40.880 --> 04:44.660 it has a LANGFIELD which determines where the string ends. 04:45.350 --> 04:51.170 I also brought a helper function that helps me to show you how strings work behind the scenes. 04:51.860 --> 04:54.580 It finds the member location of the string value. 04:54.920 --> 04:57.400 Then it converts the value to a string header. 04:57.950 --> 05:01.100 You don't need to understand how this function works right now. 05:01.550 --> 05:03.470 You just need to know how to use it. 05:03.470 --> 05:04.880 And it goes like this. 05:05.240 --> 05:09.450 You pass a string value to it and it shows you what it's doing. 05:09.480 --> 05:10.330 Heather looks like. 05:11.480 --> 05:16.700 Anyway, let me first show you what an empty string value looks like behind the scenes. 05:17.400 --> 05:22.970 I'm going to declare an empty string variable like this, then I'm going to print the fields of its 05:23.000 --> 05:23.720 string header. 05:24.170 --> 05:25.400 OK, let's take a look. 05:26.460 --> 05:28.720 As you can see, this is the street value. 05:29.190 --> 05:30.810 It's an empty string, right? 05:31.760 --> 05:37.010 And this is its pointer, it points to a new value, it doesn't point to anything. 05:37.520 --> 05:44.810 So this means that there isn't a back injury for empty strings and its length is, of course, zero. 05:45.530 --> 05:47.500 OK, let me comment on this one. 05:49.890 --> 05:53.640 Now I'm going to declare another sink value with this, how low value? 05:54.530 --> 05:56.240 Let me show you what it looks like. 05:58.110 --> 06:04.470 This time, it points to a memory address like this, so it has a back injury with five items. 06:05.250 --> 06:09.530 Now I'm going to show you go share the same back injury among the shrinks. 06:10.140 --> 06:12.300 I'm going to pass the same street value. 06:12.300 --> 06:14.100 Hello to the dump function. 06:15.110 --> 06:15.770 Let's take a look. 06:17.070 --> 06:21.400 As you can see, they're seeing headers look exactly the same, right? 06:22.110 --> 06:28.110 However, if I create another string like this one, it's string Heather will be different. 06:28.470 --> 06:29.200 Let's take a look. 06:29.940 --> 06:37.150 As you can see, even adding one more character to a string value changes its backing right here. 06:37.170 --> 06:44.310 God creates a new Badgingarra for this helo's string so it doesn't share the same backing error with 06:44.310 --> 06:45.930 the previous string values here. 06:46.850 --> 06:51.410 Now, I'm going to slice this Helo's drink variable like so let's take a look. 06:52.510 --> 06:56.980 As you can see it, Prince, the first letter, however, look at its pointer. 06:57.400 --> 07:01.380 It uses the same back injury with the previous yellow string value. 07:01.900 --> 07:05.800 So this is a proof that you can slice a string value very efficiently. 07:06.370 --> 07:09.580 When you slice it, there won't be a new allocation. 07:10.680 --> 07:16.230 Let me show you the same thing in a loop so that you can see how efficient slicing a string is. 07:18.870 --> 07:20.050 OK, let's take a look. 07:20.640 --> 07:26.730 As you can see there, Badgingarra is still the same, so slicing a shrink doesn't create a new back 07:26.730 --> 07:27.150 injury. 07:27.540 --> 07:29.370 It's very efficient and cheap. 07:30.310 --> 07:36.280 As the last examples now, I'm going to show you the effect of converting a string to a bite slice and 07:36.280 --> 07:38.380 a bite slice was was like so. 07:39.040 --> 07:40.330 All right, let's try it. 07:41.610 --> 07:48.450 As you can see, all the pointers are looking at different back injuries, so this means that the convergence 07:48.450 --> 07:54.600 allocate new back injuries, compare it to the previous back injury of the hell the variable, it's 07:54.600 --> 07:55.680 completely different. 07:56.250 --> 08:01.860 This means that unless necessary, do not convert strengths or do it only once. 08:02.770 --> 08:09.460 All right, this is how street values work and go behind the scenes by using this knowledge, you can 08:09.460 --> 08:11.110 create more efficient programs. 08:11.470 --> 08:13.420 OK, thank you for watching so far. 08:13.510 --> 08:14.830 Seeing the next lecture by.