So far, we've been pretty

bossy to the compiler. We've said, this is an integer. This is

a double. Here's a function that I want you to call. And the
compiler has sort of followed along and it's been a little bit
like an assistant who knows what's going on and says, are you sure?
Did you want to do that? Gives you a warning if you try to put,
you know, a number into an integer, that kind of thing.
Sometimes gives you an error if you try to call a function that
it's never heard of.
But you can kind of engage the compiler as your helper, your
external memory, by putting more information into your program
and then getting it to enforce it. And one of the most important
things you can say that is a particular variable doesn't actually
vary, despite the name.
There are languages in which nothing varies, even when it's called
a variable. And then there are languages where it's assumed that
everything can. In C++, and this is sort of a late motif for
us, we get to choose if we want immutability, we can have it.
If we don't, we don't have to.
So when you mark something with this keyword const, you are saying
this will not change. None of the code you're about to compile
is going to change the value of this variable. And then the
compiler will actually enforce that. And if you have a line
of code later that tries to change the value of something you've
marked const, you'll get a compiler error, basically telling
you, you can't. It's const. Why would you want to do that?
I think everyone's written the kind of code where we change the
wrong half of something. You know, we're trying to do how many
transactions have we had today and is it the limit and we mean
to raise the number of transactions and just in a moment of stupidity,
we raise the limit.
And then we're running the code on the debugger and we can't
understand it. We're never getting to the limit. The limit keeps
getting bigger. What's going on. If we had told the compiler
that the limit was const, then when we wrote that stupid line,
the compiler would have said, are you sure? Is that your final answer?
And we could have caught that mistake. And that happens all
the time to me when I used const from the very beginning.
If I declare something, like a limit, that I know isn't going
to change and I immediately say that it's not going to change,
then I catch myself when I make a mistake. And I think there's
also some speed-ups possible from that, right?
Potentially. There's a few places. But you shouldn't worry
about performance when it comes to const.
No, we don't want to premature optimize.
It's not all that important. But absolutely, you should use
const everywhere you can. If you can use const somewhere, do it.
This also actually encourages several very good programming styles.
So, for example, in many programs, especially in legacy programs,
people will reuse local variables. So they might declare one
I integer at the top of a file and then have ten loops that use
that same I.
Loops, I guess, are a bad example because you have to change those.
But you always want to use each variable in as constrained a
location as possible.
So generally, yes, you should try to make everything const, but
then things like loop variables, you should, you know, because
they can't, they...
They have to change. We're going to go around and increment
I every time through the loop.
But const by default is a good rule.
Const first, and the reason is if you ever come up to a program
where the developer despite appear to have heard of const and
you try to label something const for the first time, well, the
compiler will step up and help you and you won't really enjoy
that experience very much. And I think the demo we have is actually
going to show that by having to add const as we go through.
Yes.
All right. Let's give them a whirl through that.