WEBVTT

00:00:00.540 --> 00:00:01.430
And finally,

00:00:01.430 --> 00:00:05.440
let's discuss the last kind of a smart pointer from the standard library,

00:00:05.440 --> 00:00:07.050
the weak pointer.

00:00:07.440 --> 00:00:09.750
So what makes this pointer weak?

00:00:10.140 --> 00:00:13.400
It is weak because unlike other smart pointers,

00:00:13.400 --> 00:00:16.460
it has no ownership of resources.

00:00:16.840 --> 00:00:19.500
We could say that it has a temporary ownership,

00:00:19.500 --> 00:00:23.080
but weak pointers don't actually own anything; they are just

00:00:23.090 --> 00:00:26.860
observers of resources owned by shared pointers.

00:00:27.240 --> 00:00:31.760
I created a shared pointer and initialized it with a new complex subject.

00:00:32.140 --> 00:00:37.060
Then I can declare a weak pointer and construct it by using that shared pointer.

00:00:37.440 --> 00:00:41.580
Weak pointers cannot be constructed by a dynamic allocation on the heap,

00:00:41.580 --> 00:00:44.160
because they don't own any resources.

00:00:44.540 --> 00:00:47.260
We can either declare an empty weak pointer,

00:00:47.260 --> 00:00:51.950
or we can initialize it with another shared or weak pointer.

00:00:52.440 --> 00:00:55.720
In this case, I'm initializing it by using a shared pointer,

00:00:55.720 --> 00:00:58.870
which means that now this weak pointer points to the resource,

00:00:58.870 --> 00:01:02.310
which is owned by this shared pointer.

00:01:02.310 --> 00:01:06.950
But we cannot de‑reference this weak pointer and access the resource,

00:01:06.950 --> 00:01:10.160
because we don't know if the resource is still available.

00:01:10.540 --> 00:01:14.020
Weak pointers don't increase the control block's reference count.

00:01:14.020 --> 00:01:18.010
So this complex subject could already be released from memory when

00:01:18.010 --> 00:01:20.760
we try to access it through the weak pointer.

00:01:21.140 --> 00:01:25.200
When you decide to use this weak pointer to access the resource,

00:01:25.210 --> 00:01:30.110
you first have to lock it with the lock function. Lock

00:01:30.110 --> 00:01:34.500
function will lock this weak pointer down, and by that, I mean

00:01:34.510 --> 00:01:37.260
it will return another shared pointer.

00:01:37.640 --> 00:01:41.130
I used auto here, but you can see that this is a shared pointer.

00:01:41.140 --> 00:01:44.990
Shared pointer is always the result of the lock function.

00:01:44.990 --> 00:01:48.150
And now, there are two possibilities.

00:01:48.540 --> 00:01:50.480
If the resource is still available,

00:01:50.480 --> 00:01:54.000
this shared pointer will work like any other shared pointer.

00:01:54.010 --> 00:01:57.150
It will increase the reference count in the control block for

00:01:57.150 --> 00:02:02.060
that resource and assume ownership. Otherwise,

00:02:02.070 --> 00:02:05.760
if the resource is not available, shared pointer will be empty.

00:02:06.440 --> 00:02:11.120
I can check this by putting this shared pointer in a condition. In this context,

00:02:11.130 --> 00:02:13.800
a shared pointer will be converted into a Boolean

00:02:13.800 --> 00:02:18.160
value, and if it owns a resource, that value will be true.

00:02:18.540 --> 00:02:21.900
However, if this pointer is empty, then the value will be false.

00:02:21.900 --> 00:02:24.600
So we can create a condition to check if the resource

00:02:24.600 --> 00:02:26.910
is still available, and if it is,

00:02:26.920 --> 00:02:30.260
I want to print out both members of this complex object.

00:02:31.640 --> 00:02:32.750
Let's compile this.

00:02:33.540 --> 00:02:37.000
This will, of course, work because the lifetime of this

00:02:37.000 --> 00:02:40.610
resource is tied to the first shared pointer.

00:02:40.620 --> 00:02:45.980
But let's use the reset function on the shared pointer to manually get rid of

00:02:45.980 --> 00:02:49.950
the complex object before the declaration of the weak pointer.

00:02:50.740 --> 00:02:53.400
Now the weak pointer will try to lock on the

00:02:53.400 --> 00:02:55.860
resource that doesn't exist anymore.

00:02:57.040 --> 00:03:01.730
And if I compile this, you can see that I got our custom message.

00:03:01.740 --> 00:03:04.360
The locked shared pointer is empty.

00:03:05.540 --> 00:03:08.640
So as you can see, a weak pointer works kind of like an

00:03:08.640 --> 00:03:12.150
observer, and we are not strict about having access to the

00:03:12.150 --> 00:03:14.150
resource that it points to.

00:03:14.740 --> 00:03:17.600
We can try to access the resource when we need it, but

00:03:17.600 --> 00:03:20.590
other shared pointers that actually own the resource are

00:03:20.590 --> 00:03:22.450
responsible for its management.

00:03:22.840 --> 00:03:26.630
Weak pointers are an addition to shared pointers, and you can use them in

00:03:26.630 --> 00:03:30.030
situations where you need to temporarily observe a resource,

00:03:30.030 --> 00:03:33.060
for example, in implementing a cache system.

00:03:33.440 --> 00:03:36.930
They also solve the problem of a dangling pointer, because a raw

00:03:36.930 --> 00:03:40.590
pointer in this situation could not be sure if the resource that is

00:03:40.590 --> 00:03:43.360
pointing to is still available or not.