WEBVTT 00:00.590 --> 00:01.440 Welcome back. 00:02.000 --> 00:08.360 In the last lecture, you have learnt about bitts rooms and shrinks is lecture, you will understand 00:08.360 --> 00:09.620 how they work together. 00:10.180 --> 00:11.690 All right, let's get started. 00:12.870 --> 00:19.110 Let's start by declaring a string variable that contains some single bite and multiple bite rooms like 00:19.110 --> 00:19.500 this. 00:20.750 --> 00:27.590 First of all, let me tell you that a string value is not an ordinary bitts less a street value is read 00:27.590 --> 00:31.340 only by its slice, so I cannot change it like so. 00:31.940 --> 00:35.060 As you can see, there are errors because strings are read only. 00:36.490 --> 00:41.620 Of course, there is a solution I can convert a string value to a bite slice like so. 00:42.560 --> 00:47.270 So that I can change the elements of the bitts license that let me print it. 00:50.860 --> 00:56.680 As you can see, changing the bite size didn't change the original strength, but why? 00:57.160 --> 01:03.910 It's because starting to bite conversion creates a new bite slice by copying the bite inside the syringe 01:04.450 --> 01:06.820 so they don't share the same baking array. 01:07.330 --> 01:11.320 That is why changing the bite size doesn't change the original string. 01:11.770 --> 01:14.160 Let me show you the opposite of the conversion. 01:14.350 --> 01:17.800 So this time I'm going to convert the bite slice into a string. 01:18.430 --> 01:20.680 Do they share the same baking array now? 01:21.100 --> 01:22.390 No, they still don't. 01:22.750 --> 01:29.500 It's because the conversion creates a new string value by copying the bytes of the bytes to a new string 01:29.500 --> 01:29.830 value. 01:30.520 --> 01:36.970 So the S.R. variable contains the same string value, but it actually uses a different Badgingarra. 01:38.220 --> 01:40.530 As you can see now, the string is different. 01:41.000 --> 01:43.280 It is entirely a new string value. 01:43.470 --> 01:46.040 The original one is gone, by the way. 01:46.080 --> 01:50.040 It breaks the string, it prints some weird characters. 01:50.370 --> 01:52.690 You'll understand why it does so in a minute. 01:53.010 --> 01:56.670 So before going on, let me take the assignments back. 01:57.240 --> 02:04.410 OK, so in summary, a string is an immutable BIID slice and you cannot change any of its elements. 02:05.110 --> 02:10.230 However, you can convert it to a box less than you can change that new slice. 02:10.650 --> 02:14.550 OK, now I'm going to print the bytes slice as hexadecimal numbers. 02:15.120 --> 02:21.630 Since I created the byte slice from the estar variable, the BISLEY'S contains the same bytes as the 02:21.640 --> 02:22.650 SDR variable. 02:23.520 --> 02:27.060 Let me show you the length of the string and the bytes slice. 02:30.890 --> 02:37.850 As you can see, the number of bites in the sink and the bite slice are equal is because the land function 02:37.850 --> 02:41.030 counts the bites, it doesn't count the runes. 02:41.810 --> 02:47.210 To count the actual rules, I need to use the room count in string function LACHSA. 02:50.240 --> 02:53.810 You can also count the rooms inside the bisley's like so. 02:55.800 --> 02:58.390 These two functions do the same thing. 02:58.710 --> 03:05.700 They count the rooms most of the time there are more functions like these ones for the Sphinx and Bitts, 03:06.240 --> 03:11.370 it's because you can think of the bytes, slices and strings are interchangeable values. 03:11.910 --> 03:18.150 These mirrored functions are there to prevent you from converting a bite slice to a string or vice versa. 03:18.390 --> 03:24.440 It's because converting them between each other may allocate new memory anyway. 03:24.780 --> 03:28.320 So there are nine characters and 15 bytes in the string. 03:29.010 --> 03:32.910 That's because the string also contains non English characters. 03:33.060 --> 03:35.850 So some rooms inside the string, how? 03:35.850 --> 03:37.020 Multiple bytes. 03:37.650 --> 03:43.710 Now let me show you the bytes of the string one by one in a loop inside the loop here. 03:43.740 --> 03:47.640 I'm going to print the current index and the byte at that index. 03:48.710 --> 03:54.860 What will these print, what do you think, please pause the video and try to answer. 04:00.360 --> 04:07.650 Interesting, isn't it, the indexes don't increase one by one, instead, it appears as if they increase 04:07.650 --> 04:08.250 randomly. 04:08.850 --> 04:13.740 Let me also change this to the UTF eight encoded version of the room here. 04:17.790 --> 04:24.960 Remember, when you convert an integer, no go encodes it to UTF eight automatically, by the way, 04:24.960 --> 04:27.690 Cuerpo here prints the given room. 04:28.240 --> 04:31.410 As you can see, the second room is two bytes. 04:31.590 --> 04:34.890 That's why the range loop jumps to the top index here. 04:35.520 --> 04:43.490 Here, the Yangyang room is three bytes and the loop jumps from the seventh index to the stunt index 04:43.500 --> 04:44.170 and so on. 04:44.580 --> 04:51.510 This happens because the range loop jumps over the rules instead of the bytes in the string, and each 04:51.510 --> 04:54.880 room may start at a different location in the string. 04:55.200 --> 05:00.180 This happens because UTF eight encoding is a variable length encoding. 05:00.450 --> 05:01.620 As you've seen before. 05:01.890 --> 05:08.960 Each room may have a different number of bytes anyway, as I said, as string is a bytes less. 05:09.300 --> 05:11.980 So you should be able to use it as a slice. 05:12.000 --> 05:12.420 Right. 05:13.140 --> 05:16.210 So let's talk about indexing and slicing a string. 05:16.500 --> 05:19.800 For example, I can index the first rule laakso. 05:20.820 --> 05:22.950 But can I index the second room? 05:23.920 --> 05:31.670 As you can see, the first room is easily indexable because its length is one, but it's an ASCII character. 05:32.110 --> 05:38.010 However, the second one is not indexable easily because it has two bytes here. 05:38.020 --> 05:40.970 I only printed the first bite of the second one. 05:41.380 --> 05:44.100 That is why it prints this nonsense symbol. 05:44.950 --> 05:47.360 So how can I print the second room? 05:48.100 --> 05:53.260 Well, I can put it into a new string value by slicing the string lachsa. 05:54.630 --> 06:01.830 I slice it like this because the second room starts at the second bite of the string and it is consisting 06:01.830 --> 06:02.990 of two bites. 06:03.570 --> 06:10.230 Remember, slicing returns a value with the same type of the sliced value here. 06:10.230 --> 06:14.300 It returns a string value because the sliced value is a string. 06:14.790 --> 06:19.920 However, indexing a value returns the element type of the sliced value here. 06:19.920 --> 06:24.630 It returns a bad value because the string is a bad slice anyway. 06:24.660 --> 06:27.090 Now I can print the second run good. 06:27.930 --> 06:35.550 The last room is for bytes long so I can slice the string for the last four bytes like so it prints 06:35.550 --> 06:36.150 the emoji. 06:36.160 --> 06:36.560 Cool. 06:36.990 --> 06:40.170 As you can see, most emojis are multiple bytes. 06:40.980 --> 06:47.400 So in summary, each room in a string can have a different number of bytes, so you can't easily index 06:47.400 --> 06:53.770 a string that contains multiplied rooms in other programming languages, especially in a scripting language. 06:53.850 --> 06:55.700 They do this automatically for you. 06:56.130 --> 07:00.180 I mean, you can easily index characters, but you cannot do it with goal. 07:00.720 --> 07:02.610 The main reason is efficiency. 07:02.880 --> 07:04.840 Goal doesn't hide anything from you. 07:05.070 --> 07:09.060 It allows you to control the encoding and decoding of the characters. 07:09.360 --> 07:12.030 So you might ask, is there an easier way? 07:12.450 --> 07:13.310 Yes, there is. 07:13.320 --> 07:15.220 However, it's an inefficient form. 07:15.930 --> 07:16.590 Let me show you. 07:17.830 --> 07:21.090 You can convert the sink to Aroon Slice soap. 07:23.320 --> 07:27.190 Of course, converting a street value to our own slice has a cost. 07:27.760 --> 07:34.150 When I do so, go finds the rooms inside the string and packs them as rooms into the new room. 07:34.160 --> 07:35.380 Slice one by one. 07:35.590 --> 07:38.550 As you can see, go is an explicit language. 07:38.560 --> 07:41.410 It doesn't allow you to hide the cost of something. 07:41.950 --> 07:48.580 When the other developers or even you read the source code, they will be aware of that something costly 07:48.580 --> 07:49.600 is going on here. 07:50.520 --> 07:56.790 Anyway, why use a ruling class, it becomes very easy to calculate the length of the string. 07:58.830 --> 08:04.350 It brings nine because there are nine elements or nine rooms inside the room slides now. 08:05.280 --> 08:11.900 As you can see, this result is equal to our previous calculations here, indexing and slicing around 08:11.910 --> 08:13.680 slice is also very easy. 08:14.130 --> 08:16.500 For example, let me index the first rule. 08:18.900 --> 08:23.040 And the second to let me also say for the first five characters. 08:27.360 --> 08:32.560 As you can see, everything is correct, it seems like working with a ruling class is awesome. 08:33.090 --> 08:35.220 So why don't we use it all the time? 08:35.910 --> 08:41.670 Why gold doesn't always work with room slices and forces us to use bite slices and. 08:42.780 --> 08:43.680 What is the catch? 08:44.520 --> 08:45.250 Let me explain. 08:45.690 --> 08:48.180 First, let me print the size of the room slice. 08:49.970 --> 08:56.660 Remember, the room is an alias to interpret it, too, and it represents four bytes, for example, 08:56.660 --> 09:03.470 this room has nine elements, so it occupies today six bytes in total, however, values a string. 09:03.470 --> 09:05.610 Instead, it only uses 15 bytes. 09:06.020 --> 09:10.340 This happens because UTF eight is a variable length encoding scheme. 09:10.820 --> 09:14.240 So in UTF eight, each room can have different lengths. 09:14.800 --> 09:17.540 So it's actually a pretty efficient encoding scheme. 09:18.020 --> 09:20.490 This is why it's been used almost everywhere. 09:21.310 --> 09:27.650 Another reason is why we don't use the rules all the time is that the Gold Standard Library and most 09:27.650 --> 09:32.690 of the other libraries prefer to work with byte slices instead of room slices. 09:33.380 --> 09:34.870 So let me summarize. 09:35.300 --> 09:37.090 Let's take a look at this string value. 09:37.640 --> 09:38.780 It's a Turkish word. 09:38.840 --> 09:40.000 It means story. 09:40.610 --> 09:42.640 There are four rooms in this string. 09:43.280 --> 09:45.020 The first room has two bytes. 09:45.380 --> 09:48.530 It is between the 08 and the first index. 09:49.770 --> 09:51.590 The second room has a single bite. 09:51.840 --> 09:56.080 It is at the second index, the third one has a single bite as well. 09:56.520 --> 09:57.980 It is at the third index. 09:58.440 --> 10:01.380 The classroom has two bites, like the first room. 10:01.890 --> 10:04.730 It is between the fourth and the fifth index. 10:05.550 --> 10:11.370 When you look at it from a bird's eye view like this, you can exactly see where the rooms start and 10:11.370 --> 10:11.760 end. 10:12.160 --> 10:18.450 However, in practice, while working with UTF and encoded strings, you cannot easily see where the 10:18.450 --> 10:26.160 rooms start and stop because as you have Lawrence, UTF eight uses a variable length encoding so each 10:26.160 --> 10:29.400 room can start and stop anywhere in the string value. 10:29.970 --> 10:36.210 By the way, when you use a string, literal as in here, go in codes, the string value as UTF eight 10:36.210 --> 10:40.920 automatically for you if your source code file has also been encoded in UTF eight. 10:41.520 --> 10:43.200 So this string is no exception. 10:43.350 --> 10:45.620 It's also been encoded in UTF eight. 10:46.110 --> 10:51.110 I'm telling you this because a string value can be encoded with any type of encoding scheme. 10:51.600 --> 10:58.740 So do not assume that Ristic value is UTF eight encoded only assume that string literals are UTF eight 10:58.740 --> 10:59.300 encoded. 10:59.640 --> 11:04.890 This means that you can store anything in a string value because it only contains bytes. 11:05.400 --> 11:06.540 It's a bridezillas. 11:07.020 --> 11:12.120 So in a string value you can even store an image as sounds or a music and so on. 11:12.370 --> 11:17.850 I'm telling you this because do not assume that every string value is a valid UTF eight encoded string 11:17.850 --> 11:18.170 value. 11:18.600 --> 11:20.040 Anyway, that's all for now. 11:20.370 --> 11:21.520 Thank you for watching. 11:21.810 --> 11:25.160 Now you know the basics of bitts runes and strings. 11:25.500 --> 11:27.090 See you in the next lecture by.