WEBVTT

00:00:00.340 --> 00:00:04.010
If you're familiar with the basics of C++, you probably know

00:00:04.010 --> 00:00:06.760
what local variables are and how they work.

00:00:07.440 --> 00:00:09.260
Let's take a look at this example.

00:00:09.840 --> 00:00:13.550
I declared a variable x inside of the main function and

00:00:13.550 --> 00:00:16.160
then passed it to the printInt function.

00:00:16.840 --> 00:00:19.940
This function will take this variable as a parameter

00:00:19.940 --> 00:00:21.850
and print it out to the terminal.

00:00:22.740 --> 00:00:29.060
Both of these variables, x and a, are local variables, but what does that mean?

00:00:29.940 --> 00:00:33.670
Local variables only exist in a specific part of the code,

00:00:33.680 --> 00:00:37.780
which means that their access is restricted to a specific scope.

00:00:37.820 --> 00:00:38.950
In this example,

00:00:38.950 --> 00:00:42.660
both of the functions have their own scope. Anything written

00:00:42.660 --> 00:00:47.060
between a set of curly braces in C++ is considered as a block of

00:00:47.060 --> 00:00:49.950
code, and every block has its own scope.

00:00:50.240 --> 00:00:54.080
Everything you declare inside of this block of code will disappear

00:00:54.080 --> 00:00:57.050
once the program reaches the closing curly brace.

00:00:58.440 --> 00:01:01.120
So once you declare this local variable x,

00:01:01.120 --> 00:01:03.490
you can use it inside of this block of code.

00:01:03.500 --> 00:01:05.940
But once the main function is finished,

00:01:05.950 --> 00:01:10.040
the storage that holds this variable is released. This is

00:01:10.040 --> 00:01:12.680
known as scope‑based resource management,

00:01:12.690 --> 00:01:15.540
which implies that resources will be released from memory

00:01:15.540 --> 00:01:20.380
automatically once they go out of scope. The same rules apply for

00:01:20.380 --> 00:01:24.720
this variable, a, inside of the printInt function. You may think that

00:01:24.720 --> 00:01:28.290
this variable is not inside of the scope because we said that the

00:01:28.290 --> 00:01:31.050
scope is contained by curly braces.

00:01:31.060 --> 00:01:35.750
However, function parameters are also inside of the function scope,

00:01:35.840 --> 00:01:40.250
otherwise they would be useless if we cannot use them inside of the function.

00:01:40.440 --> 00:01:44.490
We could've also declared this variable here inside of the function's body.

00:01:44.500 --> 00:01:47.250
But the reason we didn't is because we want to use this

00:01:47.250 --> 00:01:50.570
variable as a parameter so that we can pass something in

00:01:50.570 --> 00:01:52.350
when this function gets called,

00:01:52.360 --> 00:01:56.820
just like we did here in the main function. Function parameters are

00:01:56.820 --> 00:02:00.260
just local variables tied to the function's body.

00:02:00.940 --> 00:02:05.240
Another example where we don't have to literally declare a variable inside of

00:02:05.240 --> 00:02:10.030
the curly braces is the for loop. I will create a simple for loop, which goes

00:02:10.030 --> 00:02:16.000
from 0 to 2, and prints out the iterator variable, i, in each iteration.

00:02:16.000 --> 00:02:19.160
Let's compile this to see the output.

00:02:20.240 --> 00:02:25.250
Okay, and this is exactly what we expected, 0, 1, and 2.

00:02:25.840 --> 00:02:29.820
The variable, i, is incremented by one in each iteration

00:02:29.830 --> 00:02:32.760
until this condition statement returns false.

00:02:33.840 --> 00:02:39.380
But where is this variable i declared? Is it declared in the main

00:02:39.380 --> 00:02:44.780
function scope or inside of this loop? The declaration is not

00:02:44.790 --> 00:02:48.310
inside of the curly braces, so does that mean that the variable is

00:02:48.310 --> 00:02:49.850
owned by the main function?

00:02:51.040 --> 00:02:54.760
Let's test this by printing out the variable after the loop.

00:02:56.840 --> 00:02:59.560
If I try to compile this, I will get an error.

00:03:00.440 --> 00:03:03.620
It seems that the variable, i, was not declared

00:03:03.630 --> 00:03:05.750
inside of the main scope after all.

00:03:06.340 --> 00:03:11.170
This is another exception to the rule. Just like with parameter variables,

00:03:11.180 --> 00:03:15.410
the variables declared inside of the initialization statement of the for

00:03:15.410 --> 00:03:18.860
loop are also delegated to the scope of that loop.

00:03:19.740 --> 00:03:21.750
If I really want this code to work,

00:03:21.760 --> 00:03:25.720
I would have to declare this variable outside of the loop and then just

00:03:25.730 --> 00:03:31.490
assign the 0 here. This would put the variable inside of the main scope, and

00:03:31.490 --> 00:03:34.490
since this loop is defined inside of the main scope,

00:03:34.500 --> 00:03:41.770
we are also able to access this variable inside of the loop. And if I

00:03:41.770 --> 00:03:45.360
compile this code now, we can see that there are no errors.

00:03:46.040 --> 00:03:50.160
This shows you that the scopes can also be nested. Scopes

00:03:50.160 --> 00:03:53.870
defined inside of another scope can access resources from

00:03:53.870 --> 00:03:58.960
the scope that surrounds them, but this is not true for the other way around.

00:03:59.840 --> 00:04:04.340
If I put another set of curly braces around this declaration and loop,

00:04:04.350 --> 00:04:08.140
this would create another block of code, another scope.

00:04:08.150 --> 00:04:12.440
You can already see that my code editor is warning me that this variable does

00:04:12.440 --> 00:04:17.350
not exist in this scope because this closing curly brace will clean up all of

00:04:17.350 --> 00:04:20.360
the resources declared inside of this block of code.

00:04:21.940 --> 00:04:26.690
You will often hear that C++ programmers discuss this scope‑based resource

00:04:26.690 --> 00:04:33.610
management idea by mentioning something called RAII. RAII is a term coined by

00:04:33.610 --> 00:04:38.720
the C++ creator, Bjarne Stroustrup, and it stands for resource acquisition is

00:04:38.730 --> 00:04:44.040
initialization. Even Bjarne admitted that this naming is very bad for what he

00:04:44.040 --> 00:04:48.700
was trying to convey, but the concept itself is mainly focused on resource

00:04:48.700 --> 00:04:53.550
management for objects. These simple local variables with primitive values are

00:04:53.550 --> 00:04:57.780
guaranteed to have automatic storage management. We are sure that when we exit

00:04:57.780 --> 00:05:00.760
the scope, all of the resources will be released.

00:05:01.840 --> 00:05:05.570
However, if a local variable contains some more complex object,

00:05:05.580 --> 00:05:08.560
that means that when the object is instantiated,

00:05:08.570 --> 00:05:14.150
its constructor will be called. RAII reminds us that we need to make

00:05:14.150 --> 00:05:18.510
sure that everything that gets allocated inside of the constructor needs

00:05:18.510 --> 00:05:21.360
to be deallocated inside of the destructor.

00:05:21.740 --> 00:05:25.450
This is what resource acquisition is initialization means.

00:05:25.450 --> 00:05:28.160
We will test this in the next module.

00:05:28.540 --> 00:05:33.030
For example, these resources can also be something like opening a file,

00:05:33.030 --> 00:05:35.350
which means that the stream to that file needs to be

00:05:35.350 --> 00:05:40.260
closed inside of the destructor, something that scope cannot do automatically.

00:05:40.440 --> 00:05:44.030
Another example is when you dynamically allocate memory on heap,

00:05:44.040 --> 00:05:46.180
but we will see an example of this later,

00:05:46.190 --> 00:05:50.460
once we cover what heap is and how we can use it to create smart pointers.

00:05:51.140 --> 00:05:53.040
Local variables are most common,

00:05:53.050 --> 00:05:55.880
but there are also global variables and variables

00:05:55.880 --> 00:05:58.130
defined with the static keyword.

00:05:58.160 --> 00:06:03.350
However, this is out of the scope of this lesson, and yes, pun intended.