WEBVTT 00:01.890 --> 00:02.670 Welcome back. 00:03.190 --> 00:09.570 OK, let me show you a few examples about the capacity in the coding, Ed. Let me first import my last 00:09.570 --> 00:10.170 package here. 00:10.380 --> 00:14.070 OK, so I'm going to show you the back of the slices. 00:14.070 --> 00:16.650 So I'm going to enable the print bagging option through. 00:16.890 --> 00:20.430 OK, let's start by declaring a nil string slice. 00:21.120 --> 00:21.900 Let me print it. 00:25.300 --> 00:28.010 Pay attention to its pointer, it is zero. 00:28.450 --> 00:31.060 This means that the class has no backing error yet. 00:32.060 --> 00:38.540 That is why its capacity is also zero when Venezuela doesn't have a pointer, its capacity will always 00:38.540 --> 00:40.790 be zero, but not the other way around. 00:40.910 --> 00:44.390 I mean, a slicers capacity can be zero, but it can have a pointer. 00:44.390 --> 00:48.380 As a for example, let me overwrite this slice with an empty slice. 00:48.740 --> 00:49.770 OK, let me bring to the. 00:51.600 --> 00:57.840 This time, it's pointer is not zero, but its capacity is zero, so it has a back injury but it's an 00:57.840 --> 01:03.320 empty area actually go assigns the same dummy error to all the empty slices. 01:03.810 --> 01:07.050 For example, I can create another and the slice on the fly. 01:08.760 --> 01:13.530 As you can see, even though it's a different slice with a different element type, its address is the 01:13.530 --> 01:15.070 same as a previous slice. 01:15.120 --> 01:20.460 This means that for the current go compiler, an empty slice doesn't allocate a new era. 01:21.450 --> 01:27.900 OK, let me assign a non-empty slice to the game's variable with a few retro game titles. 01:31.430 --> 01:38.000 They also printed this time, the slicers length is four, because it sees four elements from its back 01:38.000 --> 01:42.770 injury and its capacity is also four because its ERRA has four elements as well. 01:43.610 --> 01:50.360 This time its pointer is different than an empty slice because this time God creates a real back injury 01:50.360 --> 01:55.150 at this memory location and this slice points to it as an example. 01:55.160 --> 01:56.810 Let me create another slice. 01:59.550 --> 02:03.030 As you can see, it's pointer is different than the previous slice. 02:03.320 --> 02:08.780 This means that God creates different Badgingarra for the slice at a different location. 02:09.830 --> 02:15.770 Now, as an example, I'm going to show you how to use the capacity of a slice in a loop, by the way, 02:15.770 --> 02:18.270 I can do so without touching the game slice. 02:18.770 --> 02:22.880 To do that, I'm going to assign the game slice to a new slice variable like this. 02:23.210 --> 02:29.360 This creates a new slice header only for the part variable, but the game slice and the pot slice have 02:29.360 --> 02:30.410 the same baking array. 02:31.010 --> 02:32.870 OK, let me show you what it looks like. 02:34.930 --> 02:37.880 As you can see, the pointers of these slices are the same. 02:38.140 --> 02:41.410 It's because they both are looking at the same baking array. 02:42.190 --> 02:46.430 To show you my next example, I'm going to make this an attempt to slice like. 02:46.450 --> 02:48.190 So let me print it. 02:50.050 --> 02:57.100 This exploration returns, an empty slice is because the stopping position is zero, however, its capacity 02:57.100 --> 02:57.700 is four. 02:57.820 --> 03:00.310 So there are four elements in its begging array. 03:00.520 --> 03:03.560 Those gray boxes are the elements in its Badgingarra. 03:03.640 --> 03:09.220 This means that I can visualize it again and get access to these elements imagery. 03:09.520 --> 03:15.160 Now I'm going to duplicate this and I'm going to slice it up to its capacity using the cap function. 03:16.740 --> 03:23.760 I could have done the same thing like this because its capacity is far as you can see, I can visualize 03:23.760 --> 03:25.120 it up to its capacity. 03:25.680 --> 03:27.810 Now, let me slice it using a loop. 03:27.840 --> 03:31.950 First, I'm going to loop as long as the parts slices cap is not zero. 03:32.880 --> 03:37.070 Now I'm going to realize the parts lives up to its capacity here. 03:37.110 --> 03:43.980 I override the parts slice using itself because slicing returns a new slice, but it uses the same baking 03:43.980 --> 03:44.340 array. 03:44.370 --> 03:44.680 Right. 03:44.940 --> 03:47.230 You understand how this works in a second. 03:47.460 --> 03:53.190 So the loop will continue realizing the parts lies until its capacity becomes zero. 03:53.520 --> 03:54.540 Let me also print it. 03:55.440 --> 03:56.340 OK, let me show you. 03:57.920 --> 04:00.390 Oops, it goes into an infinite loop. 04:00.680 --> 04:04.190 Can you find the problem, please post a video and try to find the. 04:09.260 --> 04:15.920 The problem is in here, these slices, the parts lies beginning from its first element up to its maximum 04:15.920 --> 04:20.170 capacity, so it always returns a slice with the same elements. 04:20.180 --> 04:22.610 But I need to start from the next element. 04:22.910 --> 04:25.490 So the slice, you'll get smaller and smaller. 04:26.570 --> 04:33.050 As you can see now, it works here on each loop step, the slice gets smaller, its length and capacity 04:33.050 --> 04:37.250 decrease, but its pointer increases until the slice becomes empty. 04:37.640 --> 04:43.400 This happens because here I'm getting the next elements by throwing away the first one and I'm overriding 04:43.400 --> 04:44.360 the same slice. 04:44.360 --> 04:47.570 So its capacity and lengths get smaller and smaller. 04:47.930 --> 04:55.610 By the way, its pointer increases by 16 on each step is because, as you can see, a string value is 04:55.610 --> 04:58.230 16 bytes on a 64 bit machine. 04:58.370 --> 05:04.730 So each element of the slice is further away from one another, exactly 16 bytes, by the way, since 05:04.730 --> 05:07.060 I only overwrite the parts last here. 05:07.070 --> 05:09.170 So the game slice stays the same. 05:09.320 --> 05:11.060 Let me show you both of them first. 05:11.540 --> 05:11.930 OK. 05:12.800 --> 05:19.130 As you can see, the part is empty, but the game is not game slice is still the same because I didn't 05:19.130 --> 05:19.630 touch it. 05:19.640 --> 05:25.640 So this means that you can create different views for the same array by using different slices as I 05:25.640 --> 05:26.120 do here. 05:26.330 --> 05:28.220 This is one of the powers of slices. 05:28.460 --> 05:33.890 If I had only used the game slice instead, I wouldn't be able to access to the begging trace elements 05:33.890 --> 05:35.300 again as an example. 05:35.330 --> 05:39.860 Now I'm going to slice the game slice beginning from its last element plus one to the end. 05:40.010 --> 05:41.780 So this is equal to its length. 05:43.310 --> 05:48.590 As you can see now, the game slice is empty, like the parts slice, so I can no longer access the 05:48.590 --> 05:49.950 elements of its Pechanga. 05:50.090 --> 05:55.010 That's why I used the parts less in parallel to the game at the beginning. 05:55.790 --> 05:56.360 All right. 05:56.410 --> 05:57.140 That's all for now. 05:57.360 --> 06:00.980 If you didn't understand something, please let me know in the Q&A forum. 06:01.490 --> 06:02.330 Thank you for watching. 06:02.480 --> 06:03.100 See you soon.