All language subtitles for https___cdn.cs50.net_2022_fall_lectures_2_lang_en_lecture2.srt

[MUSIC PLAYING]

DAVID MALAN: All right.

This is CS50, and this
is week 2 wherein we're

going to take a look at a
lower level at how things work,

and indeed, among the goals of the
course is this bottom-up understanding

so that in a couple of weeks'
time, even a few years' time,

when you encounter some new technology,
you'll be able to think back hopefully

on some of this week's and this is
basic building blocks and primitives

and really just deduce how
tomorrow's technologies work.

But along the way, it's going to seem--

it's going to be a little hard, perhaps,
to see the forest for the trees,

so to speak.

And so the goal at the end of the day
still is going to be problem-solving.

And so we thought we'd begin today
with a look at some of the problems

we'll talk about or
solve this coming week,

and for that, we have some brave
volunteers who have already come up.

If we could turn on some dramatic
lighting and meet today's volunteers.

So on my left here, we have--

ALEX: Hi.

My name is Alex.

I'm a first-year at the college and
I'm from Chapel Hill, North Carolina.

DAVID MALAN: Welcome to Alex.

And to Alex's right.

SARAH: I'm Sarah.

I'm from Toronto, Canada, and I'm also
a first-year student at the college.

DAVID MALAN: Wonderful.

Well, welcome to both Alex and Sarah.

So one of the problems you'll
perhaps solve this week for problem

set 2 is to analyze the reading
level of a body of text,

whether someone reads at a first grade
level, second grade level, third grade

level, all the way up
to 12 or 13 or beyond.

What you perhaps never quite thought
about, certainly in terms of code,

like how you would analyze
some text, some book and figure

out what reading level is it at.

And yet, surely our teachers growing up
knew or had an intuitive sense of this.

So let's consider some sample text.

For instance, Alex, what
have you been reading lately?

ALEX: One fish, two fish,
red fish, blue fish.

DAVID MALAN: Wonderful.

So given that, what grade level would
you say Alex is currently reading at?

Feel free to just shout it out.

First, first?

So indeed, you'll see this week, if
you run your code on Alex's text,

it actually turns out he reads
below a first grade reading level.

But why might that be?

What might your intuition
be for why we've

accused Alex of reading at this level?

Feel free to shout out.

Yeah.

So very few syllables, short
words, short sentences.

And so there's some heuristics, perhaps,
we can infer from that short text,

that that probably means that
it's best for younger children.

Now Sarah, by contrast,
what have you been reading?

SARAH: Mr. And Mrs. Dursley of Number.

Four Privet Drive were
proud to say that they were

perfectly normal, thank you very much.

They were the last people
you'd expect to be involved

in anything strange or
mysterious because they just

didn't hold with much nonsense.

DAVID MALAN: All right.

Now irrespective of what
grade you were in when

you might have read that text,
what grade level to Sarah

seemed to be reading at?

So eighth grade, second grade.

OK.

So hearing a bit of everything, so
with that, at least according to code,

it would actually be seventh grade.

And what might the intuition there be?

Why is that a higher grade
level even though we might

disagree exactly which grade it is?

AUDIENCE: Complicated sentences.

DAVID MALAN: Yeah.

So complicated sentences,
longer sentences.

So indeed a lot more words were
being spoken by Sarah because there

was so much more there on the page.

So we'll translate these ideas
this coming week in problem set 2,

if you tackle this one, through
code so that you can ultimately

infer things of these quantitatively.

But to do so, we're going
to have to understand text.

So let's first thank our volunteers and
then we'll dive in to that lower level.

[APPLAUSE]

Sorry.

You can keep those.

SARAH: Oh, OK.

DAVID MALAN: All right.

So besides that, let's
consider one other body of text

perhaps that you might
see this week, which

is namely a little something like this.

What I have here on the screen is what
we'll start calling today ciphertext.

It's the result of encrypting
some piece of information.

And encryption, or more generally,
the art and science of cryptography

is all around us.

It's what you're using on the web,
on your phones, with your banks.

And anything that tries to keep
data secure is using encryption.

But there's going to be different levels
of encryption-- strong encryption,

weak encryption.

And what you see here on the
screen isn't all that strong,

but we'll see later today how we
might decrypt this and actually reveal

what the plaintext is that
corresponds to that ciphertext.

But in order to do so, we have to
start taking off some training wheels,

so to speak.

And believe it or not,
even though your time

would see this past
week for the first time,

probably, might have
been rather in the weeds.

And much more complicated seemingly
than C, it turns out that along the way,

we have been providing
and we'll continue

to provide certain training wheels.

For instance, the CS50
Library is one of them,

and even some of the explanations
we give of topics for now

in these early weeks will be somewhat
simplified-- abstracted away,

if you will.

But the goal ultimately
is for you to understand

each and every one of those details
so that after CS50, you really

can stand on your own and
understand and wrap your mind

around any future technologies as well.

So let's consider first the very first
program with which we began last week,

which was this one.

So "hello, world" in C. At the end
of the day, it was really the printf

function that was doing the
interesting part of the work,

but there was a lot of technical
stuff above and below it.

The curly braces, the parentheses,
words like void and include, and then

of course, the angled brackets and more.

But at the end of the day, we needed
to convert that source code in C

to machine code, the 0's and 1's in
binary that the computer understood.

And to do that, of course, we ran--

we compiled the code.

We ran make and then we were able
to actually run that code there.

So let me actually go
over here to VS Code

and really quickly recreate that hello.c
pretty much by transcribing the same.

So I might have here include
stdio.h, int main void.

And then in here, I had
quite simply, hello,

comma, world with my
backslash, endquotes, and more.

Now last time, to compile this, I indeed
ran make hello, followed by Enter.

Hopefully you see no errors
and that's a good thing.

And if you do dot,
slash, hello, you see,

in fact, the results of that program.

But it turns out that make
is not actually a compiler

as I alluded to last week.

It's a program that
clearly makes your program,

but it itself just automates the
process of using an actual compiler.

And there's lots of different
compilers out there,

and the one that it's actually
using underneath the hood

is a little something
called Clang for C Language.

And Clang is a pretty
popular compiler nowadays.

There's another one that's been
around for ages called GCC,

but these are just specific
names for types of compilers

that different people, different
companies, different groups

have actually created.

But if you use in week 1 a
compiler yourself manually,

you have to understand a
little more about what's

going on because it's even more
cryptic than what just make alone.

So in fact, let me go back to my
terminal window here, let me go ahead

and clear the screen a little bit
and just run really the raw compiler

command.

So what make is
automating for me let me,

actually do this manually
for just a moment.

So if I want to compile hello.c into
an executable program I can run,

I can do this.

clang, space, hello.c, and then Enter.

And now there's no output, which is
a good thing in this case, no errors,

but notice this.

If I go ahead and type
ls, it turns out there's

a file that's been created suddenly in
my current folder weirdly called a.out.

That stands for Assembler Output.

And long story short, that's
actually the default name

of a program that's created when
you just run Clang by itself.

Now that's a pretty
bad name for a program

because it doesn't
describe what it does.

So better would be here to perhaps do,
well, instead of a.out, which, yes,

still prints hello.world, but isn't
really a clearly-named program,

it'd be nice to name this hello.

So what could I do?

I could do like we learned last week--
well, I could rename a.out to hello

by using Linux's mv command.

So I'm going to move
a.out to become hello.

But that, too, seems kind of tedious.

Now I have three steps.

Like write my code, compile
my code, and then rename it

before I can even run it.

We can do better than that.

And so it turns out
that certain commands

like clang support what
we're going to start today

calling command line arguments.

A command line argument, unlike
an argument to a function,

is just an additional word
or key phrase that you

type after a command at
your prompt in your terminal

window that just modifies
the behavior of that command.

It configures it a
little more specifically.

So what you're seeing here on the screen
is some of a better command with which

to run clang so that now I can specify
the output of this command per this o.

So do what I mean by that?

Well, let me go ahead and
clear my terminal window again

and more explicitly type clang
-o hello hello.c and then Enter.

Nothing, again, appears to happen,
but that's a good thing when

you see no errors and now the program
I just created is indeed called Hello.

So it achieves really the same
exact effect as make did, but what.

I don't have to do with make
is type and remember something

as long as this command.

And this, too, is a bit of a white lie.

It turns out, we have preconfigured
VS Code in the cloud for you

to also use some other features
of Clang that would be even more

tedious for you to write yourselves.

And so really, this is why we distill
this as ultimately just running make.

So let me pause here to see first if
there's any questions on what I've

done by taking my very
first program in C

and just now compiling it first
with make, but then starting over

and now manually compiling
it with clang with what

we'll call command line
arguments. -o, space, hello,

and then the name of the file.

Yeah?

AUDIENCE: What is a.out?

DAVID MALAN: Yeah.

So a.out is a historical name.

It refers to assembler
output-- more on that soon.

And it's just the default file
name that you get automatically

if you just run the compiler
on any file so that you

have just a standard name for it.

But it's not a very well-named program.

Instead of running Microsoft
Word on your Mac or PC,

it would be like
double-clicking on a.out.

So instead with these
command line arguments,

you can customize the output of Clang
and call it hello or anything you want.

Other questions on what I've done
here with Clang itself, the compiler?

Yeah?

AUDIENCE: What is -o?

DAVID MALAN: So -o--

and you would only know this from
reading the manual, taking a class,

means output.

So -o means change Clang's
output to be a file called hello

instead of the default, which is a.out.

And this, too, is, again, a detail you
would have to look up on a web page,

read the manual, hear someone
like me tell you about it.

And in fact, there's even
more than these options,

but we'll just scratch the surface here.

All right.

So if we now know this, what more is
actually happening underneath the hood?

Well, let's take a closer look at
not just this version of my code,

but my slightly more
complicated version last week,

which looked a little
something like this, wherein

I added in some dynamic input from the
user so I could say not hello, world

to everyone, but hello, David or hello
to whoever actually runs this program.

So in fact, let me go ahead and
change my code here in VS Code just

to match that same code from last week.

So no new code yet.

I'm just going to, in a moment,
compile it in a slightly different way.

So I did last week's string, I think,
answer equals string, quote-unquote,

"What's your name?"

Just like in Scratch.

And then down here, instead of doing
world, I initially wrote answer,

but that didn't go well.

What did I ultimately do instead
to print out hello, David or hello,

so-and-so?

Yeah?

Sorry, a little louder?

AUDIENCE: %s?

DAVID MALAN: Yeah, so %s, the so-called
format code that printf just knows how

to deal with.

And I had to add one other thing.

Someone else besides %s--

yeah?

AUDIENCE: The name of the variable.

DAVID MALAN: The name of the variable
that I want to plug into that

placeholder %s.

And in this case, it's answer.

Now let me make one refinement
only because now we're in week 2

and we're going to start
writing more lines of code,

even though Scratch called the
return value of the ask puzzle piece,

answer always.

And see, we have full control over
what our variables are called.

And now it's probably good not
to just generically always call

my variable answer if
I'm using get_string.

Let's call it what it is.

So this is now just a matter
of style, if you will.

Let me change the variable
to be name just so

that it's a little clearer
to me, to you, to a TF or TA

exactly what that variable represents
instead of more generically answer.

All right, so that said, let me
go down to my terminal window,

and last week again, I ran make to
compile this exact same program.

Now, though, let me go
ahead and just use clang.

So clang -o--

I'll still call this version hello--

space, hello.c.

So exact same command as before.

The only thing that's different is I've
added a couple of more lines of code

to get the user's input.

Let me hit Enter, and now,
darn it, our first error.

So output from clang and
make is not a good thing,

and here, we're seeing
something particularly cryptic.

So something in function
'main--' undefined reference

to 'get_string,' string and then
linker command failed with exit code 1.

So there's actually a lot of jargon
in there that will tease apart today,

but my hint is that clearly my problem's
in main, although that's not surprising

because there's nothing
else going on here.

get_string is an issue, and the issue
is that it's an undefined reference.

And yet, notice, I was pretty good.

I added the CS50 header file
and I said last week that that's

enough to teach the compiler
that functions exist,

but the problem is that even
though this does, in fact,

teach Clang that get_string
exists, it is not

sufficient information for Clang to go
find on the hard drive of the computer

the 0's and 1's that actually
implement get_string itself.

So in other words, this
include line, per last week,

is a little bit of a hint.

It's a teaser to Clang that you're about
to see and use this function somewhere.

But if you actually want to use the 0's
and 1's that CS50 wrote some time ago

and bake those into your
program so your program actually

knows how to get input
from the user, well then,

I'm going to have to go ahead and
run a slightly different command.

So let me do this.

Let me clear my terminal window
just get rid of that distraction

and let me propose now that
we run this command instead.

Almost the same as before, clang
-o, space, hello, then hello.c,

but with one additional command line
argument at the end, and this is a -l--

not a number 1.

So -lcs with no space
in between those two.

Now the l is going to result in all
of those 0's and 1's that actually

were in by CS50 being linked into your
code, your few lines of code or mine

here.

But that's the second step that the
compiler requires in order to know how

to actually execute and rather
compile your code and CS50's.

And CS50 is not the
only one that does this.

If you use any third party library in
C that doesn't come with the language,

you would do -l such
and such where whoever--

however they've named their own library.

But you don't have to do it for built in
things like we've been using thus far.

All right, so let me
go ahead and try this.

I'll go back to VS Code
here, and let me go ahead now

and run clang -o hello, then hello.c.

And now instead of just
hitting Enter, -lcs50

with no space between the
l and the cs50, Enter.

Now nothing bad happens,
and now I can do ./hello.

What's your name?

I'll type in David, Enter,
and now we see hello, David.

Now honestly, this is where we're
really getting into the weeds,

and now this is taking--

this is really just adding nuisance to
the process of compiling and running

your code.

And so the reality is, even though
this is indeed what is happening,

this is why we used last
week and we're going

to continue using this week
onward make because it just

automates that whole process for you.

But it's ideal to understand what's
going wrong because any of the error

messages you saw for problem
set 1, any of the error messages

you see for the next few weeks
probably aren't coming from make,

they're coming from
Clang underneath the hood

because make is just
automating the process.

But with make, you literally just write
make and then the name of the program,

you don't have to worry about any
of those command line arguments.

Questions, then, on compiling
with dash -lcs50 or anything else?

Yeah?

AUDIENCE: What is the
benefit of [INAUDIBLE]??

DAVID MALAN: Sorry,
what is the benefit of--

AUDIENCE: Using Clang manually.

DAVID MALAN: What is the
benefit of using Clang manually?

None, really.

In fact, all main is doing
is just say-- make is doing

is saving us some keystrokes.

If you prefer, though, and you
just like to be more in control,

you can totally run Clang manually if
you remember the various command line

arguments.

Yeah?

AUDIENCE: So why did you
have to explain [INAUDIBLE]

DAVID MALAN: Exactly.

Why did I have to explain--

that is, provide a hint to CS50
with the cs50.h header file,

but I didn't have to do
that with standardio.h?

Just because.

standardio.h comes with C, just
like a few other libraries come

with C that we'll start seeing today.

CS50, though, is not
built into C everywhere,

and so you do have to
explicitly add that one there.

Yeah?

AUDIENCE: Can you define what
command line argument [INAUDIBLE]??

DAVID MALAN: A command line
argument is a word or phrase

that you type at the command line--

a.k.a., your terminal-- in order to
influence the behavior of a program.

AUDIENCE: OK.

So it's a term for
whatever you're giving it.

DAVID MALAN: Yeah.

It changes the defaults.

In our GUI world,
Graphical User Interface,

you and I would probably
click some boxes,

we would select some menu
options to configure a program

to behave in the same way.

At a command line interface, you have
to just say everything all at once,

and that's why we have
command line arguments.

Yeah?

AUDIENCE: Is make [INAUDIBLE]

DAVID MALAN: No.

Make is not just for CS50.

It's used globally in any project
really nowadays using C, C++,

even other languages as well.

In fact, most every command
you see in this class,

unless it has 5-0 at the
end of it, is globally used.

Only those-- a suffix with 50
are, indeed, course-specific.

And even those we'll gradually
take training wheels off

of so that exactly what those
commands are doing as well.

All right, so what is
it that we've just done?

Everything we've just done, of
course, I keep calling compiling,

but let's just go down
one rabbit hole so

that you understand that
when you compile code,

there's actually a whole
bunch of steps, happening

and this is going to enable a lot
of features, like companies can

write code and then convert it
to run it on Macs and PCs alike

or phones or the like.

So it's not just a matter of
converting source code to machine code,

there's actually four steps involved
in what you and I, as of last week,

know as compiling.

And these aren't terms that you'll
have to keep in mind constantly

because again, we're going to
abstract a lot of this away.

But just so we've gone
down the rabbit hole once,

let's consider each of
these four steps that

have been happening for you for a
week automatically, the first of which

is called preprocessing.

So what does this mean?

Well, let's consider that
same program as before.

So notice that two of the lines
of code start with a hash mark.

That is a special symbol in C, and it's
a so-called preprocessor directive.

You don't need to
memorize terms like that,

but it just means that it's a little
different from every other line.

And anything with a
hash symbol here should

be preprocessed-- that is, analyzed
initially before anything else happens.

So let's consider these two lines
up top, what exactly is happening.

Well, it turns out with
these two lines, you

have two header files, of
course, cs50.h and stdio.h.

Where are those files, because
they've never been in VS Code for you,

seemingly.

If you type LS-- if you open up
the File Explorer in the GUI,

you have never seen,
probably, cs50.h or stdio.h.

They just work, but that's
because there's a folder somewhere

on the hard drive that you're
using on your Mac or PC

or somewhere in the
cloud, as in our case.

And inside of this folder,
traditionally called /usr/include.

And user is deliberately misspelled.

It's just slightly more succinct,
although it's a little weird

why we drop that one letter.

But usr/include is just a folder on the
server that contains cs50.h, stdio.h,

and a bunch of other things as well.

So in fact, if you type in VS
Code, in your terminal window,

when you're using code spaces in the
cloud and type LS space /usr/include,

you can see all of the
files in that folder.

But we've preinstalled
all of that stuff for you.

So let's consider what's
actually in those files here.

If I highlight these two lines up top
that start with hash include, well,

I kind of hinted last week that what's
in that first file is a hint as to what

functions CS50 wrote for you.

So you can kind of think
of these include lines

as being temporary
placeholders for what's

going to become like a
global find and replace.

That is the first thing clang is going
to do is to preprocess this file.

It's going to look for any line
that starts with hash include.

And if it sees that, it's going
to essentially go into that file,

like cs50.h, and then just copy
and paste the contents of that file

magically there for you.

You don't see it visually on the screen.

But it's happening behind the scenes.

And so really, what's
happening with this first line

is that somewhere in cs50.h is
the declaration of getString

like we talked last
week, and it probably

looks a little something like this.

And we didn't spend much time
on this yet this past week,

but we will in time more.

Notice that this is how
a function is declared.

That is, it is decreed to exist.

The name of the function,
of course, is getString.

Inside of the parentheses
are its arguments.

In this case, there's one argument
to getString, I claim today,

but you've known this implicitly.

And it's a prompt.

It's the prompt that the human
sees when you use getString.

What is that prompt?

Well, it's a string of text, like
quote unquote, "what's your name?"

or anything else that I asked last week.

Meanwhile, getString, as we know
from last week, has a return value.

It returns something to you.

And that, too, is a string.

So again, this is also
called a functions prototype.

It's the thing toward
the end of last week

that I just copied and pasted from
the bottom of my file to the top,

just so that it was like this teaser
for clang as to what would exist later.

So you can think, then, of these include
lines as just kind of combining all

of those function declarations in
some separate file called cs50.h,

so that you yourself don't have to type
them every time you use the library--

or worse, so that you, yourself, don't
have to copy and paste those lines.

This is what clang is doing for you
in its first step of preprocessing.

Second, and last in this example,
what happens when clang preprocesses

this second include line?

Well, the only other function
we care about in this story

is printf, of course,
which comes with C.

So essentially, you can think of
printf's prototype or declaration

as just being this.

Printf is the name of the function.

It takes a string that you want
to format like, Hello comma world,

or Hello comma %s.

And then with dot, dot, dot, this
actually has technical meaning.

It means, of course, that you can
plug-in 0 variables, 1 variable, 2

or 10.

So dot, dot, dot means
some number of variables.

Now we haven't talked about this yet.

And we won't really, in general.

printf actually returns a value,
a number, that is an integer.

But more on that perhaps another time.

It's generally not something
the programmer tends to look at.

But that's all we mean by preprocessing,
so that at the end of this process,

even though there's more lines
of code in cs50.h and stdio.h,

what's really just happening
is that clang, in preprocessing

the file, copies and pastes the
contents of those files into your code

so that now your code knows about
everything-- getString, printf,

and anything else.

Any questions, then, on that
first step, preprocessing?

Yes?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Good question.

When you include a file,
does it only include what

you need or does it include everything?

Think of it as including everything.

So if it's a big file, that's
a lot of code at the very top.

And that's why, if you think
back to all of the zeros and ones

I showed a little bit
ago, as well as last week,

there's a lot of zeros
and ones that end up

on the screen as a result of
just writing, Hello, world.

A lot of those zeros
and ones are perhaps

coming from code that you didn't
actually, necessarily need.

But some of it is
perhaps there, but there

are ways to optimize that as well.

All right, so step two of compiling
is, confusingly, called compiling.

It's just, this is the term
that most everyone uses

to describe the whole process,
instead of just this one step.

But once a program has been
preprocessed behind the scenes

by the compiler for you, it looks
now a little something like this.

And I've put dot, dot, dot just to
imply that, yes, to your question,

there's more stuff above it.

There's more stuff below it.

It's just not interesting
right now for us.

So now we have just C code.

There's no more preprocessor directives.

At this point, all of the hash
symbols and those lines of code

have been preprocessed and
converted to something else.

And so now-- and this is where
things get a little spooky looking.

Here now is what happens
when clang, or any compiler,

literally compiles code like this.

It converts it from this in
C to this in assembly code.

So this is among the scarier languages.

I, myself, don't really
have fond memories.

This is not a language that
many people program in.

If you take a subsequent
class in computer science,

in systems, a higher level
class, you might actually

learn this or some variant thereof.

But there's at least
a few people out there

that need to know this
stuff because this

is closer to what the computers
themselves, nowadays, understand.

The Intel CPUs or the AMD CPUs, the
brains of today's computers and phones

understand stuff that looks
more like this and less like C.

Now it's completely esoteric, but
let me just highlight a few phrases.

There's some stuff
that's a little familiar.

There is mention of main
at the top there in yellow.

There is mention of
getString toward the bottom.

There is mention of printf down below.

So this is just another programming
language called assembly language,

that decades ago, humans--

myself included in school--

did write code in.

And absolutely, some people
still write this code,

especially since you can write
very, very efficient code.

But it's a lot more arcane.

It's a lot less user friendly.

So you'll see in yellow now, these
are the so-called instructions

that a computer's brain or CPU
understands, pushing values

around, moving them, subtracting values,
calling functions, and move, move,

move.

So really, the low-level operations
that computers understand

tend to be arithmetic operations--
subtraction, addition,

and the like-- moving
things in and out of memory.

It's just a lot more tedious for
folks like us to write code like this.

This is why you and I tend
to write stuff like this.

And ideally, still, people like you and
I tend to drag and drop puzzle pieces

that sort of abstract
all of that away further.

But for now, this is, again,
called assembly language.

It is what happens when the compiler
literally compiles your code.

But of course, this,
still not zeros and ones.

So we got two steps to go.

So when a compiler
proceeds to step three,

this is where things get
converted to machine code.

And when a compiler
assembles your code for you,

it converts what we just saw on the
screen here to actual zeros and ones--

the so-called machine code that your
phone or your computer understands.

But it's worth noting that
these are not necessarily all

of the zeros and ones of your program.

Yes, they are the zeros and ones
that correspond to your Hello program

or printf and getString
and the like, but notice

that here, we need one final step.

In those zeros and ones are
only your lines of code.

But what about CS50's lines of code
that we wrote to implement getString?

What about the lines of code that humans
wrote decades ago to implement printf?

Those are somewhere on this hard
drive, like on my Mac, my PC,

or somewhere in the cloud, but we need
to combine all of those zeros and ones

together and link my code with
CS50's code with standard I/O's code,

all together.

And so what happens in
the last step, ultimately,

is that if we have my
code here in yellow,

and then the code that CS50 wrote,
and the code that the authors of C

itself wrote, what really is happening
is that somewhere, we have not only

hello.c, which, obviously, I
wrote, and wrote with us live here,

there's also, let's assume, somewhere
on the computer, a cs50.c file

that, coincidentally, I and
CS50 staff wrote years ago.

And also, somewhere on the
computer, there's another file.

Let me oversimplify by
just calling it stdio.c.

In practice, it's probably
specifically called printf.c.

But they're somewhere,
these two other files.

And so this last step called
linking takes my zeros and ones

from the code I just wrote, namely
this code on the screen here.

It then grabs the zeros
and ones that CS50 wrote.

And it grabs the zeros and ones
that the authors of C wrote,

in order to implement
the standard I/O library.

And lastly, voila,
links them all together.

And this is the same blob of zeros
and ones that we saw earlier.

It's just now the result
of preprocessing your code,

compiling your code, assembling your
code, linking your code, and my God,

at this point, like if there were
any fun in programming for you yet,

we've just taken it all away, we just
call this whole process compiling.

Why?

Because now that we
know those steps exist--

and smart people solve
that problem for us--

you and I can kind of operate
at this level of abstraction

and just assume that compiling
converts source code to machine code.

Questions, though, on any
of these intermediate steps?

Yeah?

AUDIENCE: For linking, are
different parts, like [INAUDIBLE]??

DAVID MALAN: A good question.

So where are all of these
zeros and one stored?

Because you and I, we've been using
a browser, right? code.cs50.io,

of course, is this
web-based user interface.

But again, recall from last
week, even though you're

using a web browser to access VS Code,
that web-based version of VS code

is connected to an actual
server somewhere in the cloud.

And on that server, you have your own
account and your own files, and really,

your own hard drive,
virtually in the cloud.

Think of it a little like Dropbox
or Box or Google Drive or OneDrive

or something like that.

So you have a hard drive somewhere out
there that we've provisioned for you.

And it's on that hard drive that you
have your code that you just wrote,

or I just wrote, cs50.c, stdio.c,
and all of the other code

that implements the math functions
and everything else that C supports.

Good question.

Yeah?

AUDIENCE: So, say in the CS50
library, the line [INAUDIBLE]

do we do the same
exact thing [INAUDIBLE]

copy paste them all the way over?

DAVID MALAN: Good question.

That hash includes cs50.h
line at the top of my code.

If I just replace that with the
contents of cs50.c, would that work?

Short answer, yes, that would work.

You could copy all of the code there.

However, there's some order of
operations that might come into play.

And so it's probably not quite
as simple as copy, paste.

But conceptually, yes,
that's what's happening.

Now with that said, in cs50.h, are
only the prototypes of the functions,

the hints as to how the functions
look, what their return type is,

what their name is, and
what their arguments are.

It's in the dot c file that
actual code tends to be written.

And this is a little confusing
now because you and I have only

written code in dot c files.

But in the next few
weeks, you'll actually

start writing some of
your own dot h files

as well, just like CS50,
just like standard I/O.

But in essence, that line of code
just makes it easier to use and reuse

code that's already been written.

And that's the whole point of a library.

AUDIENCE: Does linking them [INAUDIBLE]?

DAVID MALAN: Say that a little louder.

AUDIENCE: Does linking happen
when you use the compiler?

DAVID MALAN: Yes.

Does linking happen when
you compile your code?

Yes.

When you run make, as we have
been doing the past week now,

all four of these steps are happening.

Preprocessing converts the hash
include lines to something else.

Compiling technically
converts it to assembly

code, which the Mac, the PC, the
server more closely understands.

Assembly converts that language to
binary machine code that this computer

actually understands.

And then linking combines
everything together.

And in fact, if you think back a few
minutes ago to when I did this -lcs50,

the reason I had to add
that, and the reason

my code did not compile
at first, was because I

forgot to tell clang to link in CS50's
zeros and ones per that last step.

I don't need to do -lstdio
because it comes with C,

so that would just be tedious
for everyone in the world.

But CS50 does not come
with C, so we link that in.

And to be clear, too, we won't
always use CS50's library.

That'll be yet another pair of training
wheels we take off in the coming weeks.

But for now, it makes
a few things simpler.

Yeah?

AUDIENCE: What is the [INAUDIBLE]?

DAVID MALAN: Short answer, yes.

So what do the zeros and ones,
the machine code, translate to?

Yes, there is a one-to-one
relationship between the machine

code and the assembly code.

Assembly code, it's not really English,
but at least it's symbols I recognize.

It's not zeros and ones.

Machine code, of course,
is just zeros and ones.

So back in the day,
before C existed, people

were programming only in assembly code.

Before assembly code existed, people
were coding in zeros and ones.

And you can imagine just
how painful that was,

and so each of these
languages makes life, for us,

sort of easier and easier.

In a few weeks, we'll
transition to Python, which

will, in turn, make C even simpler--

or coding, in general,
simpler to do too.

All right, so with that
said, what now can we--

what could go wrong with this?

Well, it turns out that besides
compiling, technically speaking,

there's decompiling.

And we've not done this,
and we won't do this.

But it's worth considering
for just a moment.

If you were to not compile
your code, but decompile it--

as the word suggests, this just means
reversing the process, converting it,

ideally, from machine
code-- zeros and ones--

maybe back to C. Now this would be cool,
perhaps, if all you have is a program,

you can convert it and see
the actual source code.

What might a downside be,
if anyone on the internet

is able to decompile
code on their machine?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: OK, so it's easier
to find bugs in the code that--

oh, to exploit.

So it might be easier to
hack into the software

by finding mistakes you and I
made because, literally, they're

staring at you in code,
whereas the zeros and ones make

it way less obvious.

Other downsides of what
I called decompiling?

Yeah?

AUDIENCE: If stuff is copyrighted or
you don't even know how to get it--

DAVID MALAN: Yeah.

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Yeah, if
your code, your work,

is your intellectual property,
copyrighted or otherwise, that's

kind of obnoxious that someone
can just run a command, and boom,

they can see the original
code that you wrote.

Now, it turns out it's not
quite as simple as that.

And so even though, yes, you
could take a program like Hello,

or even Microsoft Word, and
convert it from zeros and ones

back to some form of source
code-- be it in C or Java

or Python or something else, whatever
it was originally written in-- odds

are it's going to be an
utter mess to look at.

Why?

Because things variable names are
not retained in the zeros and ones,

typically.

Function names might not be
retained in the zeros and ones.

The code is, the logic
is, but the computer

doesn't care what pretty
variables you chose

and how nicely named your
functions were, it just

needs to know them as zeros and ones.

Moreover, if you think about last week,
we introduced things like loops in C.

And besides for loops, there's what
other kind of loop, for instance?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: So, a while loop--
and even though they look different

and you have to write different
code, they achieve exactly

the same functionality, which is
to say, when you compile a for loop

or you compile a while loop, if
they logically do the same thing,

they might end up looking
identical as zeros and ones.

And so, therefore, it's
not necessarily predictable

that you'll get back
the original code, why?

Because the zeros and ones
might not know, so to speak,

whether it was a for
loop or a while loop,

so maybe compiling will
show you one or the other.

And honestly, decompiling,
while possible-- and it's

one way of reverse
engineering someone's product.

Odds are, if you're good enough to start
reading code that's been decompiled

and reading through the
messiness of it, odds are you

have the talent probably to just
write that same program from scratch

yourself.

Now, that's an overstatement,
perhaps, but it's not

quite as easy or threatening
as you might first think.

So in general, once
code is compiled, it's

pretty challenging, time consuming,
costly to reverse engineer it, much

like it would be in
the real world, right?

Like all of us have some kind of phone,
probably, nowadays in our pocket.

There's nothing stopping you
from opening it up somehow,

poking around, recreating what's there.

That's a huge amount
of effort, most likely.

And at that point, maybe you should
just invent the phone, instead

of trying to reverse engineer it.

So same kind of idea
in the physical world.

Any questions, then, on compiling,
or even decompiling in these forms?

All right, so odds are, at this point,
not only I, but you have made mistakes.

And you've written buggy code--

a bug in a code is just a
mistake, a logical error

or otherwise, where the code just does
not behave correctly as you intend.

And up until now, odds are,
your debugging techniques

have been to maybe look back
at what I did in class, maybe

ask a question online or in-person.

But ultimately, it'd be nice if
you had some tools of your own

with which to debug code.

And this, honestly, is a lifelong skill.

You're not going to emerge from CS50--

and even 20 years from
now, you're not going

to be writing-- if you're writing code
at all-- correct code all of the time.

Like, all of us on the staff
continue to write bugs.

Hopefully, they get a little more
sophisticated, and not sort of like,

oops, I missed a semicolon.

But even those kinds of
mistakes, we make too.

But there's tools out
there and techniques

that can make your life easier when
it comes to solving those problems.

Now, the term bug has actually
been around for decades.

But a fun story to tell is that
the first documented actual bug was

actually somehow connected to Harvard.

In fact, this is the logbook relating
to the Harvard Mark II computer

from 1947, whereby if you read the
notes here-- and I'll Zoom in-- this

was an actual moth discovered inside
of this big mainframe computer that

was causing some kind of problems.

And the engineers there
at the time actually

thought it was funny that, wow, physical
bug actually explains the issue.

And it's been forever taped to this
sheet of paper, which I believe

now is on display in the Smithsonian.

With that said, this is just
representative, too, of a logical bug.

And that story is actually--

that story was often retold by a famous
mathematician, then computer scientist

really, Dr. Grace Hopper, who actually
worked not only on the Harvard Mark II

computer, but its predecessor,
the Harvard Mark I.

And if you ever spent time, yet, in the
engineering building across the river

here, you can actually see
much of this computer, which

is along the wall when you first
walk into the Science and Engineering

Complex.

And indeed, as you've
probably heard growing up,

this is a mainframe computer.

This is what Macs and PCs, so to
speak, looked like back in the day,

with very physical things that
essentially implemented the zeros

and ones that you and I take for granted
now being miniaturized in our laptops

and phones.

So there's a piece of history there.

If you visit that side of
campus sometime, do take a look.

But let's consider, then, how we
solve not, of course, physical bugs,

but logical bugs.

And let's consider something
like this from last week,

whereby, we were trying very simply to
print like this column of three bricks

using hashtags of sorts.

So let me go over here in
just a moment to VS Code.

And I'm going to go ahead and
open a program I wrote in advance.

And I'm bringing it to class
because there's a bug in it,

and I'd like to figure
out how to solve this bug.

So let me open up a buggy0.c,
which is version 0 of my code.

And let's just take a
quick peek at what's here.

It's pretty short.

It includes only stdio.h, it
uses printf, it uses a for loop,

and the goal, quite simply, is to
print out that column of three bricks.

Now, it's short enough that some of you,
if you're getting comfy already with C,

you might already see the logical bug.

It's not a syntax error,
like it will compile and run.

But there's a bug there.

And suppose that I'm very new to C, I'm
very uncomfortable with C, it's 2:00 AM

and I just can't see the bug, what
are my recourses here for actually

finding a mistake like this?

Well, first, let's look at the symptom.

Let me go down to my terminal window.

I'm going to use make buggy0 because,
again, the file is called buggyo.c.

I'm not going to use clang.

In fact, I'm never really going
to use clang manually here on out.

I'm just going to use make
because it makes our lives easier.

It does compile.

No errors, so it's not syntax.

It's not something silly
like a missing semicolon.

But when I run ./buggy0, I, of
course, see one, two, three, four--

and this, of course, does not match the
one, two, three bricks that I actually

intended for that column.

And yet, I'm starting counting
at 0, as I usually do.

I've got three.

I'm going up to three.

So where is my logical error?

If it hasn't obviously jumped out at
you already, well, how can I solve this?

Well, first and foremost,
perhaps the best technique

for solving bugs, at least
early on, is just use printf.

Like thus far, we've used sprint say,
Hello, and other things on the screen.

But printf is just a function
for printing anything.

And there's no reason
you can't temporarily

use printf to print out
the contents of variables,

what's going on inside
of your program, just

to figure out where your mistake is.

And then you can delete
that line of code later.

It doesn't have to stay there forever.

So let me do this.

Instead of just printing out
in VS Code the hash symbol,

let me do a little safety check
here and print out the value of i.

So let me go ahead and
say something like, i is--

now I want to say i is this.

But, of course, this is not
how I print out the value of i.

If I want to print out the value
of i, what should I put here?

So %i for integer,
instead of %s for string.

So they're still placeholders.

But we use %s for integers.

And now if I want to print out i, I just
need the comma as the second argument,

and then i.

All right, let me go ahead and
back to my terminal window.

Let me recompile the program
because I've changed it.

That still works fine, ./buggy0.

And now, let me increase the
size of my terminal window here.

You just see some diagnostic
information, if you will.

This is not the goal.

This is not what you should be
submitting for this homework problem,

were it one.

But it is helping us diagnostically
know that, OK, when i is zero,

here's a hash.

When i is 1, here's a hash.

When i is two, here's a hash.

When i is 3, here's a hash.

Well, wait a minute.

That's one, two, three, four.

So clearly, I'm printing
it one too many times.

So let me look back at the code here
by shrinking my terminal window.

And let me just ask the group,
where is, in fact, the mistake?

Or what, equivalently,
would be the solution?

Yeah, in the middle.

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Yeah, instead of less
than or equal to, use just less than.

So you've got to kind
of pick a lane here.

If you're going to start counting
from 0, you generally use less than,

and go up to, but not through the value.

Or if you prefer, like in the
human world, counting from 1 on up,

you can use less than or equal
to, but you have to be consistent.

And in general, as a
programmer, just always start

counting from 0 if you're doing
something canonical like this.

But the solution is,
indeed, just to change this

by changing the greater less
than or equal to the less than.

If I recompile this program with make
buggy0, and then do .buggy0 again--

and let me increase the
size of my terminal window.

Now, you see, OK,
almost the same output.

But indeed, i starts at 0 and goes
up to, but not through, three.

All right, so printf, in short,
can be your first diagnostic tool.

Instead of just staring at the
screen or raising your hand--

I mean, use printf to see, literally,
what's going on inside of your program

by just printing out things of interest.

And then once you've
solved the problem, you

can go back into your code, as I'll do
here, by shrinking my terminal window.

I'll delete the printf line.

And now I'm ready to share
this program with the world

or submit it as homework or the like.

It's just meant there to be temporary.

Any questions on printf
as a debugging tool?

No?

All right, well, that
only gets us so far.

And honestly, as your programs
grow and grow and grow,

it's going to actually
get really annoying

to start going in and adding printf's,
then removing them, and figuring out,

if you've got multiple printf's,
well, which one printed what?

It just gets messy, eventually,
to rely on printf alone.

So being a computer
scientist, computer scientists

have written software to
make it easier to debug code.

That software is what we would
generally call a debugger, which

would be the second tool of the trade
that you can use to actually solve

problems in your code.

Now, in the world of VS code,
there's actually a debugger built in.

So the graphical user
interface you're about to see

in VS Code isn't specific to CS50,
it actually comes with VS Code.

And it supports C, and
C++, and Java, and Python,

and lots of other languages too.

But it's, admittedly,
a little complicated

to just start using the debugger.

You have to create a
configuration file and do

some annoying steps that just get
in the way of solving real problems.

So we have automated the process for
you of just starting the debugger.

And thereafter, it's sort of
industry standard how you use it.

But we save you the headache of having
to create those configuration files.

So, suppose I want to do this.

Suppose I want to try
to debug this program

step by step using special software.

Well, how can I do that?

Well, let me propose that if I revert
this back to the original version

where i was less than or equal
to 3, I'm pretty sure that I

was printing too many hashes.

So I'm going to do this--
and you might have done this

accidentally or never at all.

But notice if you hover over the gutter,
so to speak, in VS Code, the part of it

all the way to the left of the
editor, you see this sort of grayed

out red dot.

If you click there, it
becomes a brighter red dot.

And this represents what we're
going to call a breakpoint.

And this is just a visual indicator that
you've put like a stop sign equivalent

there, and you're telling the
debugger in a moment, stop

running my code there.

Why?

Because I prefer to step through
my code at sort of a human speed,

and not as computer speed
where it runs all at once.

So I've set my breakpoint,
which is step one.

And then step two is quite simply this.

Instead of running the program itself,
run the command called debug50,

and then ./buggy0.

And now this will start
your program, but inside

of the debugger, which
is a special program

that smart people
wrote that will empower

you to now step through your code line
by line, and again, at your own comfort

pace.

I'm going to hit Enter, some stuff's
going to happen on the screen-- whoops.

Notice, this is a common mistake
that I made accidentally here.

Looks like I've changed my code.

I did because I went in and changed
the less than or equal to sign.

So let me go ahead and
rerun make buggy0--

Enter.

Good, now let me rerun debug50--

Enter.

And now some stuff just
happened on the screen

and it takes a moment to get
started but once it's started you'll

see this you'll still see your code.

But you'll see this yellow highlight,
which you've probably not seen before.

And notice that it's specifically
highlighting the same line

that I set a breakpoint on.

Why?

That just means the debugger
has executed all of these lines,

except for line 7.

It has broken at-- not in a bad way.

But it has paused execution on line 7,
so it hasn't yet printed any hashes.

And you can see that-- no hashes
in the terminal window yet.

It's paused execution.

But what's interesting with
the debugger is the stuff

over here on the left-hand side.

In the debugger here,
you'll see, under variables,

all of your so-called local variables.

And we haven't really made
a distinction between local

and something called global.

But for now, local variables
just means all of the variables

that exist in your function.

So i currently has a value of 0.

OK, and that makes sense.

So now, how do I step through
my code and see what it's doing?

Well, at the top of
the screen here, you'll

see some playback icons,
kind of like a video player,

but they have special meaning.

This first one will just play the rest
of your program all the way to the end.

So you only click that if you've
sort of solved the problem

and you just want to run it
to completion like before.

But the next three--

or next two, really,
are really the juiciest.

The second one here, if you
hover over it, eventually,

you'll see that it's called Step Over.

Step Over means that
the debugger will run

this currently highlighted line of code,
but it's not going to dive into it.

So if it's a function
like printf, it's not

going to start stepping
through printf line by line.

Why?

Because I can pretty much assume
printf, written decades ago, is correct.

Problem's probably with me.

But this next line, if I did really
want to step into the printf code

to figure out how it works or find some
problem in it all these years later,

you can step into printf, and
then the screen would change,

and you'd see each of
the lines for printf,

line by line-- at least if you have
the source code for printf installed.

All right, I'm going to use
the first one, Step Over.

And watch as the yellow highlight moves.

And watch as, in the terminal
window, there's a hash symbol.

Here we go.

There's one hash.

Now, notice line 5 is highlighted.

That means it has paused on line 5.

Line 5 has not yet been executed.

So what does that mean?

The value of i, per the top
left-hand corner, is still 0.

But as soon as I click
Step Over again, watch

what happens at the top left, where
i is a variable on the screen.

Now i-- and it flashed briefly--

has a value of 1.

And now if I step over again,
watch the terminal window.

There's my second hash.

Now, let me click Step Over on for
loop, watch the variable at top left.

Now 1 goes to 2.

Now let me click it again.

Third hash-- and here's where the
logical error is perhaps revealed.

Let me go ahead and step over the loop.

Now i is 3.

Wait a minute, I'm still
going to print out a hash.

There it is.

There's the fourth hash.

And at this point, hopefully, the
light bulb, proverbially, has gone off.

I realize, oh, I screwed up.

I can either stop the program
altogether with the red square,

or I can just let it run all
the way to the end, which

just terminates everything.

At this point, I just want to get back
into my code and start fixing things.

And you can close, for
instance, as I will here,

the File Explorer, just to
hide the panel that opened.

So that's debug50.

But it's not a CS50 thing, that just
starts the debugger for you, which

is something you'd find in most any
programming environment nowadays.

Questions on debugging?

Questions?

Yeah?

AUDIENCE: Where does it tell
you where it went wrong?

DAVID MALAN: Good question.

Where does it tell you
where it went wrong?

So, sadly, it does not
tell you any of that.

The onus is still on you, the human,
to use this tool productively to walk

through your code at a saner pace.

But your brain is the one
that still needs to solve it.

And I don't doubt, down the line,
with artificial intelligence and more,

programs like this will
get all the more helpful,

and start answering
questions like that for us.

And there are other tools we'll
introduce you this semester

that are even more powerful than this.

But for now, it's just a tool,
really, to slow things down and not

have to change your code.

The fact that I had that panel on the
left that just showed me i's changing

value is just an alternative
to printf, and I can

step through it a little more slowly.

Other questions on debugging?

No?

Let me show you one final
example with this debugger here.

And this one, too, I wrote in advance.

Let me close buggy0.c.

And let me open up buggy1.c,
my second version thereof.

Let me close my terminal
window for a second

and give you a quick tour
of this program, which

similarly, has a mistake.

Now, at the top of this program, some
familiar includes, cs50.h and stdio.h.

This is not something we've seen before.

It's specific to this example--

a function called getNegativeInt.

Takes no arguments, and
it returns an integer.

What does it do?

It literally gets a negative
integer, ideally, from the user.

Fun fact, though, it doesn't correctly.

That's the bug. getNegativeInt
is broken at the moment.

So what does main do?

Well, main just calls this
function, passing in nothing

in parentheses, no inputs.

And it stores the return value in i.

And then it just prints
out i on the screen.

So honestly, just by eyeballing
this, I feel comfortable enough

with programming in C,
I think main is correct.

Let me just stipulate, main is correct.

But there is going to
be a bug down here.

Now, what's the bug down here?

Well, let me look at
getNegativeInt's implementation.

Notice, this first line, 12, is
identical to the prototype up here.

The prototype is sort of
stupidly required up here

because C reads things top
to bottom, left to right--

the compiler technically does.

So if you reference
getNegativeInt here, but you

don't implement it until down here,
and you haven't told C in advance

that it will exist, again, you
get the error we saw last week.

All right, so how does
getNegativeInt work?

We declare a variable called n.

We've got to do while
loop that does what?

It uses getInt, which comes with
the cs50 library, per last week.

It prompts the user for
negative integer, quote unquote,

and stores the value in n.

I then do all of this while
n is less than 0, right?

Remember, we used to do while loop last
week to make sure the human cooperates

and doesn't give us the wrong type
of value, be it positive or negative

or something else.

And then we return n.

And there's some subtleties.

Anyone recall-- or have an intuition
for why I've declared n on line 14,

instead of line 17?

This is a C specific thing.

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Exactly.

There's this notion of scope in C. And
we'll continue to see this over time,

whereby, a variable only exists
inside of the most recent curly braces

that you've opened.

So if I've declared n here
on line 14, I can use it

anywhere between lines 13 and 21 because
those are the nearest curly braces.

If by contrast, as you note,
if I instead said this,

int n equals getInt and so forth,
and didn't have the current line 14,

well, n would exist inside of these
curly braces, but not here, which

is too late, and definitely not here.

So you just have to declare it first,
and then use and reuse it as such.

Now, let me just show
you how I can debug this.

But let me show you the symptoms first.

Let me open my terminal window.

Let me run make buggy1.

Compiles OK, so it's not something
silly like a semicolon. ./buggy1,

and I'm asked for a negative integer.

All right, let me give it negative 1--

Enter.

Well, the main function is
supposed to print out what I typed,

but it clearly didn't.

It's prompting me again.

All right, so maybe
it'll like negative 2.

No?

Maybe negative 3.

50?

OK, so it's definitely broken, right?

It kind of seems logically
to be doing the opposite.

Now, you can perhaps see why
this is happening already.

These are deliberately simple
programs for demonstrations sake.

But let's do this.

Let me go ahead and set
a breakpoint in main,

even though I'm pretty
sure main is correct.

But it just helps me start my
thought process-- start with main,

and then take it from there.

Let me run now, debug50 ./buggy1--

Enter.

And let's see.

With that breakpoint now, the GUI
is going to reconfigure itself.

It's going to pause on line 8 because
that's the first interesting line

inside of main.

So I could have just put the
breakpoint on line 8 too.

It's smart enough to know
that if I set it on 6,

you really mean line 8 because
that's the first actual line of code.

And watch, now, what happens.

If I step over this line, notice
that i, which at the moment

seems to have a default value of 0--

more on that another time.

But if I click Step Over like before,
I'm prompted for a negative integer.

Let me type negative 1--

Enter.

And now, notice, there's no
additional yellow highlight.

Why?

Where am I currently stuck, logically?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Yeah, just logically,
I must be in that do, while loop.

And even if you don't understand it,
like that's the only explanation.

If you keep getting prompted,
surely, there's a loop going on.

There's only one loop in my code,
so there's probably a problem there.

So I can't just set a breakpoint in
main, and then wait for this to work.

So let me just--

let me stop this with the red square.

And let me think, all
right, instead of--

I can still set my breakpoint in main,
but let me rerun the debugger instead.

And this time, not step
over that line of code,

let me step into that line of code.

So watch what happens now.

Instead of clicking
the second icon here,

let me click the third, whose
name is, indeed, Step Into.

And watch as the yellow highlight
does not move to line 9.

It dives into line 8--
the function on line 8,

thereby, bringing me down to line 17.

It's kind of going down
into that next function.

Now, it didn't bother pausing
on line 12 or 13 or 14

because there's nothing intellectually
interesting there happening yet.

The juicy part really starts,
it would seem, in line 17.

So, now notice, n is my
variable at the top left.

If I click--

I don't want to click
Step Into now, though.

What would go wrong if
I click on Step Into--

or what would it do that I
don't think I want to do?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Yeah, it
would step into getInt.

But I'd like to think that the
staff's version of getInt is correct,

and that's not our problem
today, so I want to step over it.

And watch now at top left that
nothing happens yet to the value of n

until I go to the terminal window
now, and I type in something

like negative 1.

Now notice, it jumps to line 19,
which is the next interesting line.

Top left, n, indeed, is negative 1.

And here's where I can
now pause as a human

and think, all right, so
while n is less than 0.

All right, n, per the top
left corner, is negative 1.

So all right, while
negative 1 is less than 0,

well, obviously that's
true mathematically.

So what's going to happen?

It's a do while loop.

So when I click on Step Over again,
it's going to go to this line

because it's at the end of
the inside of that loop.

And now here, it's looping
through again and again.

All right, let me do this once more.

I'm going to step over, all right?

I'm going to type in negative 2,
and it's the exact same thing.

Now is my chance, on the yellow line--

OK, wait a minute.

Negative 2 is obviously less than 0.

Let me try this one more time.

Click it once here.

All right, let me give it 50.

And now, OK, while 50 is
less than 0, that's not true,

so the loop is over because it's not
going to do it while 50 is less than 0.

That's not true.

So now watch, when I
click Step Over once more,

it then finishes the loop, even
though there's nothing more to do.

It's now about to return n.

It jumps back up to main,
where I left off on line 9.

It now prints, in my terminal
window, the number 50.

And hopefully, at this point,
to your question earlier,

my human brain has realized, oh, I'm
an idiot, like I flipped my sign there.

So I probably-- let me stop this.

I probably want to do
something like this.

If the goal is to get a negative
integer, I probably want to say,

while n is, for instance, greater
than or equal to 0 would work.

So while n is greater than or
equal to 0, keep doing this.

And that's the logic
I wanted to express.

So the debugger just saves me from
staring at the screen, raising a hand,

sort of asking someone else.

At least in this case, it allows me
to go through it at a healthier pace.

Questions now on debug50, which should
be your new friend, even if it's not

your first instinct after printf?

Any questions on debug50?

No?

All right, well, there's one last
technique we can equip you with here.

And that is, in addition to
printf and a debugger, no joke,

a rubber duck is actually a
reasonably recommended solution

to finding bugs in your code.

To your question earlier,
the duck two is not

going to solve the problem for you.

But if you've wondered why this
little guy has been here for so long,

there's this technique, has
its own Wikipedia article

of called rubber duck debugging.

The idea of which is that if
you're home in your dorm room,

wrestling with some bug
in your code, printf

didn't quite reveal the source to
you, debugger isn't really helping,

honestly, maybe it would help to just
sound out what problem you're having.

Similar to going to office hours,
talking to a TA or a professor,

just walking through
your problems because

in sort of talking to
the duck about the fact

that you're doing this while n is
less than 0, and then if it is--

wait a minute.

I'm an idiot, not just for
talking to the rubber duck.

You realize, hopefully,
in expressing yourself,

literally verbally, you probably
will hear with non-zero probability,

like some illogic in your statement.

And just by sounding things out, you'll
realize like, oh, that's my problem.

And so, frankly, if you have roommates,
you can also use a roommate for this.

But the rubber duck is
just sort of a go-to

when your roommates have no
interest in your C problem set,

talking something through that as such.

And this is an invaluable technique.

I admittedly tend not to do
it so much with a rubber duck,

but ideally with colleagues,
human colleagues.

But just talking through things
often will help you just realize,

oh, I said something illogical.

Now I can go back to the code.

So don't solve problems
by staring at your screen

endlessly for minutes, for hours.

At that point, it's
time for a break, time

to walk away, time to talk to
the duck, if you've already

exhausted some of those other tools.

As an aside, on your way out
today at the end of class,

we have, clearly, plenty
of rubber ducks for you.

And it's become a thing
over the years, at least

among some, to bring the duck with them
when they travel and send us photos.

Here, for instance, is CS50's
rubber duck debugger, A.K.A. DDB,

for Duck Debugger, which is a pun on
a geekier program called GDB, the GNU

Debugger, which is an actual
piece of software for debugging.

This is CS50's debugger in the hills
of Puerto Rico, also, here on the sea.

He made its way to San Francisco here.

Also, down by Fisherman's
Wharf by the sea lions.

Familiar?

Here at Stanford, where there's
a William Gates Computer Science

building for computer science,
down the road in SF at Google.

And this is the Trevi Fountain in Rome.

And lastly, the Colosseum.

So we'll be curious to see in the coming
years where your duck two travels.

So that, then, was quite a bit.

Why don't we go ahead here and
take a short 5 minute break?

No snacks yet.

You're welcome to get up or sit down.

We'll return in about five.

All right, so we are back.

And if the goal, ultimately, today is
to have a better understanding of things

like strings so that we can
solve problems with text,

let's consider some
simpler types of data

first, how we might
represent those, and then

see if that doesn't lead us to
a discovery as to how strings,

and just today's modern software
is using things like that.

So when we talked on week zero
about representation of data,

we had different ways of doing it,
in terms of binary and decimal,

and unary even.

When we started talking about
the same last week in code,

we started talking about
data types instead.

And these data types
were a way of telling

the computer, like do you want an
integer, do you want a character,

do you want a floating point value,
like a real number, or even a string,

as we've seen?

But it turns out that
computers, of course,

only have finite amounts of resources.

Your computer only has a
fixed amount of memory or RAM.

And that actually has very
real world implications.

So for instance, here are some of
the data types we've seen thus far.

And it turns out that each of
these in C has a specific number

of bits allocated to it.

Now, admittedly, this
can vary by system.

It's not so much the case
nowadays, but for many years,

for decades, computers were
getting better and better.

The earliest computers
might have used fewer bits

for some of these data types.

More modern computers
might use more bits.

So the numbers you're about to see are
pretty much where we are present day.

So when it comes to
these data types, a bool,

which is true or false, somewhat
curiously, uses a whole byte,

even though that's way overkill
because for a bool, true or false,

you, of course, only need one bit.

But it turns out, even
though it's wasteful to use

eight bits, or one byte, just
to represent true or false,

it's just easier for computers.

So a bool tends to be one byte.

An int, which we've been using a lot,
uses 4 bytes, typically, or 32 bits.

And if I do some quick math
from week zero, with 32 bits,

you have 4 billion
possible values, roughly.

But if you want to represent
positive and negative,

that means you can represent roughly
negative 2 billion, all the way up

to positive 2 billion.

So that's the range,
typically, with ints.

If that's too few numbers for you,
turns out there's things called longs.

And longs use 64 bits,
which allow you to have

like a quintillion
number of possibilities,

which is a lot, certainly,
a lot more than 4 billion.

So sometimes you might use a long.

But even that's finite.

And so as we discussed
at the end of last week,

bad things can happen if
you make certain assumptions

as to the data because of things
like integer overflow or the like,

where things wrap around.

Then there's a float, which is a real
number, something with a decimal point.

By convention, it's 4 bytes or 32
bits, which gives you, in short,

only a specific amount of precision.

It doesn't necessarily dictate how many
numbers to the left or to the right.

In the aggregate,
ultimately, you have though,

4 billion possible permutations still.

If you need more precision
for scientific, for medical,

for financial applications, you
might use 8 bytes, A.K.A. a double,

which just gives you
more digits of precision.

They eventually get imprecise per
the example we looked at last week,

but it at least gets you
further down the line.

As an aside, in really, really
important applications, in finance,

in medicine, in military
operations, and the

like where you really can't
have rounding errors--

long story short, humans have developed
libraries in C and other languages

that use more, even, than 8 bytes.

So there are solutions to these
problems, but they're always finite.

You have to pick an upper bound.

Then there's char, which we saw
briefly last week when I asked

the user for y or n, for yes or no.

And then there's a string, which I'm
going to propose as a question mark

because a string totally depends.

Like, Hi!

H-I, exclamation point,
would seem to be three bytes.

D-A-V-I-D, would seem to be five.

So the strings, clearly, are variable
based on what you or the human type in.

So we'll see what this
means, though, in just a bit.

This though, is the thing inside
of your Mac, your PC, your phone.

It might not look exactly
like this, but this is

a memory module for a modern computer.

And let's go ahead and use this.

Really, it's just representative
of the finite amount of memory

that any computer, indeed, has.

Let's zoom in on one of these little
black chips on the circuit board here.

Zoom in, and let me propose that
this rectangle really represents

some number of bytes, like tucked
inside of this little black circuit

on the board is maybe, I
don't know, a gigabyte,

a billion bytes, maybe it's 100
bytes-- some number of bytes.

It totally depends on
the computer and how much

you paid for the stick of memory.

But if there's a finite number of
bytes physically implemented somehow

digitally inside of this
hardware, well, then it

stands to reason that we
could number those bytes.

We can just arbitrarily decide that
the top left corner is byte number

one, or really byte number zero.

The one next to it is
number one, then number two,

number 3, dot, dot,
dot, number 2 billion

or whatever it is, however
big this memory is.

So if you use a variable in a C
program, that's only one byte.

Like a char, it might literally be
stored in that top left-hand corner

of the memory.

In practice, you don't care
where, physically, it is.

But really, the artist's
rendition would be

this-- a char might use
one of those single bytes

somewhere in the computer's memory.

If you use an int, which is
4 bytes, it would give you

4 bytes, contiguous-- that is
left to right, top to bottom.

But all 32 bits would
be next to each other

so the computer knows that those,
indeed, all belong to the same int.

If you need a long, or a
double for that matter,

then you might use a full
8 bytes in this case.

And you just keep using
and using this memory,

kind of like a canvas,
almost in Photoshop

or a spreadsheet where you can just
move pixels or you can move data around,

that's really what your
computer's memory is,

a canvas for storing information
in units of bytes or 8 bits.

Now, we don't need to keep
looking at these circuit boards.

We can abstract it away, as we often do.

And let's go ahead and
zoom in on this grid,

just to consider some
very specific variables.

So let me zoom in, and now I
see fewer, but larger boxes

on the screen, each of which,
again, represents a byte.

And now let me propose that
we play with some actual code.

So here in C, albeit
without a full program,

are three ints-- score1, score2, score3.

I have, coincidentally, given
myself two scores around 72 and 73,

and then a pretty low score at 33.

Of course, last week or two weeks
ago, this would have been high.

But now we're dealing
with actual integers.

So these are three so-so scores on
my quizzes or tests or the like.

So let me go to VS Code here.

And let's make a
program called scores.c.

So I'm going to write, code scores.c.

That's going to give me my new file.

And let me go ahead and
implement something like this.

Include stdio.h, int main(void),
and then inside of here,

let me do int score1 will be 72.

Int score2 will be 73.

And int score3 will be 33.

And then let me just do
something like write a program

to average my three test scores
together, something like that.

So let me do printf, quote
unquote, my average is--

and I'm going to go ahead
and do, say, %i, /n.

And now, let me plug in the results.

And this is kind of
grade school math now.

How do I compute the
average of three values?

Well, just like on paper, I can
do score1 plus score2 plus score3

in parentheses, because of order
of operations, divided by 3,

since there's three total scores.

All right, so I think this checks out.

And indeed, you can use parentheses
and operators like plus in your code

like this in C. Let me go
ahead now and do make scores.

No syntax error.

So that's good, nothing missing there.

And now let me do ./scores and
see what my test average is.

All right, it's not great,
but I think I still passed.

And indeed, my average here is 59.

Is it precisely 59 though?

Well, let's see.

Let's actually, instead of using
an int, how about we go ahead

and use something like a
floating point value here?

And let me go ahead and do this.

So let me recompile
my code, make scores.

Huh, all right, I've got an issue.

Let me zoom in on my terminal window.

We've not seen this one,
necessarily, before.

But error on line 9.

Format specifies type double,
which is a lot of precision,

but the argument has type int.

So what does this mean?

Well, it's showing me with these green
squiggles that something's bad between

the %f and this thing over here.

Well, on the left, I'm implying a
float, or a double for that matter.

On the right, though, what data
type are score1, score2, score3?

All right, so they're ints.

So clang does not like this.

The compiler just doesn't like
that I'm using ints on the right,

but I want floats on the left.

So there's going to be
different ways of solving this.

One way would be to just ignore
the problem like I originally did,

and just go back to %i.

Or as an aside, %d is often an
alternative to %i for a decimal number.

But we use %i because it sounds
like int, so %i is fine here too.

But I don't want to
just avoid the problem.

I want to actually display
a floating point value.

So how can I fix this?

Well, it turns out, I can solve
this in a few different ways.

The simplest is just to make sure
that at least one number on the right

is a floating point value,
like 3.0 instead of just 3.

Now I think clang will be happier.

Let me do make scores--

Enter.

And indeed, it's OK.

Why?

As soon as you have at least one
more precise data type on the right,

it just treats everything, at that
point, as floating point value

so that the math works out.

So ./scores, Enter-- and
now, there we go, right?

Some of us might really
want that 1/3 of a point.

Our average was not 59.

It's 59 1/3, as in this case here.

All right, so we've solved that there.

As an aside, though, there's one
other technique to show here.

If you didn't want to change
it to 3.0 because that's

a little weird, because there
were literally three scores,

it's not like that needs
to have a decimal point,

you could also explicitly
convert the 3 to a float

by saying, in parentheses, float.

This is what's called typecasting.

And this will just convert the thing
right after it to that data type,

if it's possible.

So if I do this again, make scores,
no errors now. ./scores, and I get,

in fact, the same result. There's
a bit of a rounding issue here,

but we know the rounding relates
to the imprecision from last week.

For now, let me just be
happy with my 59.3 something.

I'll take that for now.

But this is as close to a good
enough correct answer for me now.

But how do I--

think about now, what's going on
inside of the computer's memory?

Well, let's consider.

Here's that same grid of memory.

Each box represents a byte.

Where are score1, score2,
and score3 in my memory?

Well, score1, let me just
propose, is at the top left.

But it's taking up
four boxes for 4 bytes.

Score2 probably ends up
right next to it in memory,

though, this isn't always
going to be the case,

but I've chosen simple examples.

73 is next to it, also
taking up 4 bytes.

And then lastly, 33 is in
score3, down there underneath.

Now, if we really look
at the computer's memory,

look at it with some kind
of microscope or the like,

there's actually 32
bits, 32 bits, 32 bits

in each of those four groups of four
bytes representing those values.

But again, for today's
purposes onwards, we

don't really need to think
again and again in binary.

It's just, indeed, these decimal
numbers being stored there.

But I claim now, this
isn't the best design.

Even if you have never
programmed before CS50,

what you're looking
at here on the screen,

as an excerpt, in what sense is this
perhaps bad design, even though it's

a correct way of storing
three test scores?

What's kind of bad here?

Yeah?

AUDIENCE: The more scores you
have, the more you [INAUDIBLE]..

DAVID MALAN: Yeah, always do
exactly what you did-- extrapolate

to 4 scores, 5 scores 50 scores.

This can't be that
well-designed because now you're

going to have 4 lines of
code, 5 lines of code,

50 lines of code that
are almost identical,

except for this like
arbitrary number that we're

updating at the end of the variable.

So indeed, there's probably
going to be a better

way, even though, at least in C,
we haven't yet seen that technique.

But the solution, today onward, is
going to be something called an array.

An array is a way of
storing your data back

to back to back in the
computer's memory in such a way

that you can access each
individual member easily.

Put another way, with an array, you
can instead do something like this.

Instead of saying int score1,
int score2, int score3,

giving each a value, you
can first tell the computer,

please give me a
variable called scores--

plural, though you can
call it anything you want--

of size three, each of
which will be an integer.

That is to say, this is how you
declare an array in C that will have

enough room to store three integers.

Put another way, this is the
technical way of telling the computer,

please give me 12 bytes in total--

3 times 4 each for an int,
so give me 12 bytes in total.

And what the computer
will do is guarantee

that they're back to back to
back in the computer's memory.

And that'll be useful in just a moment.

So let me go ahead and do
something useful with this.

Let me store three actual scores.

Here's how I could now store those
same numeric scores in this array.

Syntax is a little different, but
there's one variable called scores.

But if you want to go
to its first location,

starting today, you use square
brackets and go to location 0

first, which because things in
C are 0 indexed, so to speak,

you start counting at 0.

The first int is at [0].

Second int is at [1].

Third int is at [2].

So it's not one, two, three.

It's literally 0, 1, 2.

And this is not something
you have control over.

You must start at 0.

So these lines now create
an array of size three,

and then insert one, two,
three values into that array.

But the upside now is that you only have
one name of the variable to remember.

It's just called scores.

Yes, you need to go into the
array to get individual values.

You need to index into it
using those square brackets.

But at least you don't
have this hackish approach

of declaring a separate variable for
each and every one of these values.

So let me go back to scores.c here.

And let me propose that I do this.

Let me just use that same
idea to do the following.

Let me get rid of these
three separate integers.

Let me give myself an int
scores array of size 3.

And then scores[0]
will, as before, be 72.

Scores[1] will be 73.

And scores[2] will be 33.

And let me get rid of
the little dot there.

All right, so now, if I go ahead and
run this again with make scores--

Enter.

Huh, what did I do wrong here?

I think I got a little
too ahead of myself.

Let me increase my terminal window.

Let's focus on line 10 here, first.

Error, use of undeclared
identifier, score1.

What did I do here that was dumb?

Yeah?

AUDIENCE: You didn't
declare it a variable.

DAVID MALAN: Right, so
I didn't declare score1.

I've got old code.

So I just kind of, honestly, got ahead
of myself here, not even intentionally.

So let me go ahead and shrink
my terminal window again.

I need to finish my thought here.

So let me clear my terminal.

And let me change this now to
be scores[0] plus scores[1] plus

scores[2].

So it's a little more
verbose because I've

got these square brackets, so to speak.

But I think now my code is consistent.

So let me make scores now.

It now compiles.

./scores gives me, indeed, the same
rough average with those same values.

All right, so let me go ahead and
maybe enhance this a little bit.

It's a little silly to have to
write a special program just

to check your average of three
test scores like 72, 73, 33.

Why don't I actually
make the program dynamic

and ask the human for those scores?

So instead, let me do this.

How about we get rid of the
72, and change this to getInt.

And I'll just prompt
the user for a score.

Let me get rid of the 73 and get this
to be getInt score, quote unquote.

And then lastly, get rid of the 33, and
replace it with getInt, quote unquote,

score.

getInt is a CS50 thing for now, so
I need to include cs50.h, as always.

But I think now, it's
sort of a better program

because now I can compile it once,
I can even share it with my friends.

And now any of us can average
three scores on some classes test.

They don't need to know the
code or rewrite the code just

to type in their scores.

So make scores worked.

./scores, now I can type anything
I want-- maybe it's a 72, 73, 33,

still get the same answer.

Or maybe I'm having a better
semester, 100, 100, maybe 99,

and now we get still a
pretty high score there.

But now it's dynamic.

Now you don't need the source code.

You don't need to recompile the program.

It's just going to work again and again.

But this, too.

Let me propose that this
code is correct if I

want to get three scores from the user.

But these highlighted lines now, 6
through 9, are they well-designed,

would you say?

Yeah?

AUDIENCE: Can you loop?

DAVID MALAN: Yeah, right?

This is-- we can use a
loop, is the spoiler here.

Why?

I mean, my God, it's like the same
code again and again and again.

The only thing that's
changing is the number.

And this should have kind of
had some code smell again,

because if I keep typing the
same thing again and again,

that's clearly an opportunity
to better design something.

So let me do this.

Let me go ahead and still
create my array of size three.

But let me use our old friend,
the for loop, for int i equals 0,

i less than 3, i++.

And then in here, let
me do scores bracket--

we haven't seen this
before, but any intuition?

Scores bracket--

AUDIENCE: i.

DAVID MALAN: i, because that will
use whatever i is, be it 0 or 1 or 2

in iteration.

And then I can get an int,
asking the user for score,

without having to repeat
myself again and again.

So hopefully, if I didn't make
any typos, make scores, all good.

./scores, 72, 73, 33, and
we're back in business.

But the code is arguably
now better designed,

because now, I haven't
actually hardcoded the scores,

and I haven't actually copied
and pasted any of that code.

Well, if we consider now what's going
on inside of the computer's memory,

it's pretty much the same
in terms of the values.

But instead of the variables being,
literally, score1, score2, score3,

there's just one variable.

It's an array called scores.

But you can index into its three
locations by using scores[0] to get

the first, scores[1] to get the
second, scores[2] to get the third.

But this is key.

The memory is contiguous.

The screen is only so
large, so it wraps around.

But physically, digitally,
the memory is contiguous-- top

to bottom, left to right.

And that's important, why?

Because the brackets indicate 0,
1, 2, that each of these integers

is just one integer away from the next.

It can't be randomly down
here all of a sudden.

It's got to be back to back to back.

All right, now equipped
with that paradigm,

what more could we actually do here?

Well, it turns out, it's worth
knowing that it's possible in code

to even pass arrays around as arguments.

And let me just whip this
program up somewhat quickly,

just so you've seen it before long.

But let me go ahead and do this.

Let me propose that I create a function
that does this averaging for me.

So I'm going to create a function
called average that returns a float.

And the arguments this
thing is going to take--

let's see, it's going to be the array.

So it turns out, if you want to
take in an array of numbers--

you can call it anything you want.

This is how you tell C
that a function takes, not

an integer, but an array of integers.

And you don't have to call it array.

I'm doing that just for
the sake of discussion.

It can be called x.

It can be numbers.

It can be anything else.

I'm just calling an array to be super
explicit as to what it is there.

Now, how do I change my code down here?

What I think I'm going to do
for the moment is just this.

I'm going to get rid of this code here,
where I manually computed the average.

And let me just call the
average function here

by passing in the whole array of scores.

So this is just an
example of abstraction,

like now I have a
function called average.

I don't care.

I don't have to remember how
it works once I implement it.

It just kind of tightens up
my main code a little bit.

But I do still have to implement this.

So later in my file-- let
me repeat myself before,

the only time it's OK in C to
repeat yourself again and again,

by typing out again, average,
and then int array open bracket--

but now not a semicolon.

Now I have to implement this thing.

And I can implement this in
a bunch of different ways,

but I don't know in advance--

I can't just do this.

I can't just do array[0]
plus array[1] plus array[2],

unless this program's only ever
going to work on three numbers.

So let me go ahead and do this.

Let me first propose that
there's a poor design here.

In my main function, what
value have I repeated twice?

Among the highlighted lines,
what jumps out at you as twice?

AUDIENCE: The length of the array?

DAVID MALAN: Yeah, the length
of the array, it's just three.

Now it's not a huge deal that I typed
the number three on line 8 and line 9,

but this is exactly the
kind of like shortcut

that's going to get you
in trouble eventually.

Why?

Because, eventually,
you or someone else is

going to go in and make the
array bigger or smaller,

and you're not going to
realize that magically,

that same number is in two places.

And indeed, this is what a programmer
would often call a magic number.

A magic number is one that
just kind of appears magically.

And you're on the honor system to
change it here, if you change it here,

and then you change it over here.

That's not going to end well if
the onus is on the programmer

to remember where they hardcoded--
that is, wrote out three explicitly.

So any time you reuse a value
like this, you know what?

We should probably do what we did last
week, which was to declare a variable,

perhaps at the very top of my
program, so it's super obvious

what it is, called, maybe
n, and set that equal to 3.

Better yet, what did I
do last week to make sure

that I can't screw up and
accidentally change that value?

Yeah, constant.

And the keyword there
was just const for short.

And now I have a global variable--
global in the sense that I can

access it anywhere-- that is called n.

It's an int.

And it's always going to be 3.

And now I can improve my main
function a little bit by just changing

the 3's to n, so now if I, if a
colleague realized, oh, wait a minute,

there's four tests this year.

You change n to four,
recompile the code,

and it just works everywhere else,
except in my average function.

Let me change it back to
3, just for consistency.

This is not going to fly now, to just
sum up things like this, for instance,

and then return this divided by 3.

Why will this not work
now as I've defined it?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: OK, I might be
returning an integer value when

I intend to return a float per this.

But I think I'm OK because I used
that little trick where I made sure

that at least one of the numbers
in my arithmetic expression

is, in fact, a floating point value.

And just by adding the point
0, make sure that everything

gets treated as a float.

So I think that's OK.

AUDIENCE: [INAUDIBLE]

DAVID MALAN: I'm sorry, a little louder.

AUDIENCE: It just seems
like you're [INAUDIBLE]..

DAVID MALAN: Exactly.

So left hand's not
talking to the right hand

here, in that my current
implementation of average

is still assuming that there's only
going to be three tests or whatever.

But wait a minute, I just
went through the trouble

of modifying this to be n, generically.

And if I change this to 4, I'm
not going to be happy, perhaps,

with my average because now I'm
going to ignore one of my test scores

altogether.

So let me change this back to 3.

And unfortunately, if
it's a variable now,

n, and therefore, I have literally
a variable number of scores,

how do I take the average of
a variable number of things?

I mean, what's my building block there?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Yeah.

Why don't I use a loop that goes through
the array and adds things up as you go?

I mean, kind of like grade school, as
you take the average on your calculator

or paper and pencil, you just
keep adding the numbers together,

and then you divide at the end
by the total number of things.

So how can I do this?

Well, let me change my
implementation of average

to first declare a variable called
sum, or whatever, set it equal to 0.

So this is like me on my piece
of paper getting ready to count,

or my calculator, of course, when you
turn it on, typically defaults to zero.

And now, let me do for, int i
equals 0. i is less than a--

well, no, I didn't do that.

i is less than n, i++.

And now in here, let me go ahead
and add to the current sum, whatever

is in the array's location, i.

And then down here, I think I can
just return some divided by 3.0--

not 3.0, n, perhaps here.

And actually, I think I'm going to
get-- let's make sure it's a float.

Let's use the type casting trick just
to make sure I don't accidentally

shortchange someone and throw away
everything after the decimal point.

So it just escalated quickly, right?

Average just got a lot more involved.

It's not just a single one line
of code, but now it's dynamic.

I initialize a variable called sum to 0.

In this loop, I go through and just keep
adding to sum, which is initially 0,

whatever's in array[i]--

or specifically array[0],
array[1], array[2].

That gives me a total sum that I return,
divided by the total number of things.

Now, this I can tighten slightly.

Recall that this is syntactic
sugar for just adding things.

I can't use plus plus because
that only literally adds one.

But I can use here, plus equals.

Questions on this implementation here?

Really the only takeaway-- or
the most important takeaway

is that this is the
syntax for how you tell

a function that it
expects a whole array, not

a single variable like
an int or the like.

You literally use
square brackets, but you

don't specify the length inside there.

Yeah?

AUDIENCE: What variable
[INAUDIBLE] at the top?

DAVID MALAN: What about
the variable at the top?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Good question.

What do I have it defined as at the top?

This variable, N, it must be an integer
if you're going to use it inside

of an arrays square brackets here.

So this line 10, notice, no
longer says 3, it says N.

And so whatever N is 3 or 4 or
something else, that's how many

integers I will get in that array.

And it must be, by definition
of an array, an integer that

goes in those square brackets.

And here's a common source of confusion.

When you create the
array, that is declare it,

you use square brackets
like this, where you put

the total number of elements you want.

When you subsequently use the
array, like I'm doing here,

you don't mention int again--
just like you don't mention int

again and again once a variable exists.

You use the square brackets still, but
you don't use N. You use 0 or 1 or 2

or, generically here, i.

So when C was designed, they
sometimes used the same syntax

for two different ideas or contexts.

Yeah?

AUDIENCE: Do you have to
include line 6 [INAUDIBLE]??

DAVID MALAN: Good question.

Do I have to include line 6?

Short answer, yes, because of
the reason we ran into last week.

C, or clang really, reads your
code top to bottom, left to right.

And so if the compiler sees some mention
of this function average on line 16,

but you haven't told the
compiler that average exists,

you're going to get an
error on the screen.

So the conventional
way to do that is you

just copy paste the first line
of code from the function,

it's so-called prototype or declaration.

Yeah?

AUDIENCE: Is there a library if you
don't know the size of the array?

DAVID MALAN: Really good
question, and a perfect segue way.

Is there a library you can use if
you don't know the size of the array?

No.

And so if any of you have programmed
in Java or Python or other languages,

you can actually just ask
the array, how big is it?

In C, you and I, the
programmers, have to remember it.

And so short answer, no,
there's no function that

will just automatically do this for us.

And in fact, let me
make a more subtle claim

that it's fine to use global
variables like this if they're really

for configuration options.

Why?

It's just convenient to put
them at the very top of the file

because everyone, you,
your colleagues, your TAs

are going to see them
at the top of the code.

But you really shouldn't be using
them everywhere throughout your code.

It'd be better if the average
function, itself, were

independent of that special variable.

So by that, I mean this.

You know what I should really do, if
I really want to be well-designed?

I should pass in the length of
the array to the average function.

I should give the average
function a second argument--

I'll call it length, for instance,
but I could call it anything I want.

And so rather than putting N all the
way down here at the bottom of my file,

let me just dynamically
say length instead.

And this is a subtlety-- and no need
to get too tripped up over this.

But this, now, is just an example
of how the same function can

take not one, but two arguments.

But indeed, in C, you must remember,
yourself, what the length of an array

is.

You can't just ask the
array via some syntax

like you can, those of you who've
programmed before in Java or Python.

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Good question.

Would it be better designed to write
a function that computes the size?

Short answer, can't do that in
C. As soon as you pass an array

into a function in C, you cannot figure
out its size if it's a generic array

like that of integers.

There are special cases
that you can do that.

But in general, no, it's
just not possible in C.

And if that's some
frustration, honestly, this

is why more modern
languages add that feature.

Why?

Because it was really
annoying, as I'm alluding here

to not having that information.

Now, just to make sure I
didn't screw up anywhere,

let me compile this
final version of scores.

Suspense.

All good. ./scores, 72, 73, 33,
and we're still back in business.

So this version is more complicated.

And as always, we'll have this version
on the course's website for reference.

But the point, really,
is that arrays, not only

can be used as containers
to store multiple values--

three or more in this case--

you can also even pass them
around as arguments, as such.

All right, now besides that,
let's simplify for just a moment,

and consider now the world of chars.

If we've just got single
bytes, where does this lead us?

And how does this get us,
ultimately, to strings

to solve problems like readability
and cryptography and the like?

Well here, for instance,
are three lines of code,

out of context, that
simply store three chars.

And you can already see
where this is going.

Having three variables
called c1, c2, c3 is clearly

going to end up being bad design because
of all the silly redundancy here.

But notice, I'm using
single quotes like last week

because these are single chars.

What does this look like
in the computer's memory?

Well, it looks a little
something like this.

If we clear out the old
memory, c1, c2, c3 probably

will end up here, maybe not literally
in the top left-hand corner.

This is just an artist's rendition.

But c1, c2, c3 will
probably end up like that.

Now, what's really there?

It's really those same three numbers--

72, 73, 33.

But how many bits does a byte have?

Just eight.

So if we were to look at the binary
representation of these characters,

it would only be eight bits each.

That's enough to store small
numbers like 72, 73, 33.

We're not dealing with Unicode
and emoji and the like.

But the point is the same.

You don't have to use four
bytes to store these numbers.

You can use a different data type
like chars, and underneath the hood,

it's, indeed, going to use
just single bytes for each.

But this is sort of like a-- this isn't
really how we implement strings, right?

When you wanted to say, hi, last
week, or this, we used double quotes.

And we wrote all of the things together
and used one variable, not three,

right?

When I typed in David, I didn't
have a variable for D-A-V-I-D.

I had one variable called name
that stored the whole thing.

So in C, we keep talking about
these things called strings.

We'll see, eventually, that strings are
not necessarily what they seem to be.

But for now, the key thing
about strings is that they're

variable length, so to speak, right?

They might be three characters,
Hi, or five characters, David,

or anything smaller or larger.

So how do we go about
implementing strings,

if all we have at the end
of the day is my memory?

Well, here is an example of
just creating, declaring,

and defining a string called s. s
because it's just a simple string,

and quote unquote,
HI!, in double quotes.

What does this look like
in the computer's memory?

Well, let's clear it again.

And here, now, because it's
technically stored in one variable,

s, here is how I might
draw it as an artist.

It's three bytes in total--

H-I exclamation point.

But there's no c1, c2, c3, it's
just, the whole thing is s.

But it turns out that
a string, fun fact,

is really just what underneath the hood?

Kind of leading up to this--

what is a string, if this is
how it's laid out in memory?

AUDIENCE: An array.

DAVID MALAN: Literally, it's
just an array of characters.

And we didn't have to know about
arrays last week to use strings.

This is where, again, the training
wheels are starting to come off.

But a string is just
an array of characters.

H-I exclamation point, for instance.

So technically, an array--

or a string called s is really a
variable called s that allows you

to get at the first character with
s[0], if you want-- s[1], s[2].

You can literally get
individual characters

just by treating s as though
it's an array, which it really

is underneath the hood, in this case.

But there's a catch.

How do you know where strings end?

In the past, when I drew
some integers on the screen,

I know, I claim they
always take up 4 bytes.

If I had drawn a long, it
always takes up 8 bytes.

If I had drawn a character,
it always takes up 1 byte.

But how many bytes
does a string take up?

Yeah, I mean, that's
kind of the right answer.

In this case, three, it would seem.

But if it's David, that's
a good five characters.

But where do we put the number three?

Where do you put the number five, right?

This is literally all
that's inside your computer.

This is all our building
blocks in front of us.

So how can we-- where does the three go?

Where does the five go?

Well, it turns out you can solve
this in a couple of different ways.

But the way humans decided to implement
strings years ago is, indeed, an array,

but they added one extra byte at
the end of every such string array,

just to make clear, with a
so-called sentinel value,

that the string ends here.

Why?

So that if you have two strings
in the computer's memory like, HI!

and bye, you know where the barrier is
between the exclamation point of one

and the letter B in the next, right?

You need some kind of delimiter.

And so what really is
underneath the hood is this.

When you store a string in memory, when
you type in a string-- as the user,

if you type in 3 characters,
it's going to use

3 plus 1 equals 4 bytes in total.

If you type in David, it's going to
use 5 plus 1 equals 6 bytes in total.

Why?

Because C automatically adds this
special 0 at the end of the string.

I've drawn it with backslash 0 because
this is how you represent 0 as a char,

as a character.

But this is literally
just 0, as we'll soon see.

So any time there's a string
in memory, it always takes up

one more byte than you, yourself,
as the programmer or human typed in.

In fact, if we convert this
again, just for discussion's sake,

to those integers, what's literally
stored in the computer's memory

is going to be 72, 73, 33, and now a 0.

And the computer, because of
C and how it was invented,

it's just smart enough to know
that when you print out a string,

it prints out every
character until it sees a 0,

and then it just stops printing.

In particular, printf
knows how this works.

And this is why printf
knows when to stop printing.

Decimal numbers are
not that enlightening.

We'll generally write
the characters like this.

And again, backslash 0 is
just special symbology.

It's what the programmer types to make
clear that you're not saying, HI!, 0.

You're saying HI!, and
then it's a special 0.

Specifically, it is eight
0 bits that indicate

that it's the end of the string.

Technically, that backslash zero, if
you want to be fancy, it's called null,

N-U-L-L.

And it turns out, you've seen this
before, though we didn't call it out.

Here's that same ASCII chart
from the past couple of weeks.

If I highlight this, what is
decimal number 0 mapping to?

NUL, which is just programmer speak
for the special null character.

All 0 bits that means
the string ends here.

This all happens automatically for you.

You do not need to create these
null characters or these zeros.

Any questions then, on this
implementation thus far?

Any questions here?

No?

Well, let me do this.

Let me go back to VS Code in a second.

And let's actually corroborate
this with some code.

Let me go ahead and create
a small program called hi.c.

And how about we do this?

Let me include stdio.h.

Let me include-- let me type
out int main void, as always.

And now let me do something
simple and kind of bad,

but char c1 equals quote
unquote, h, in single quotes.

Char c2 equals quote
unquote, I, in single quotes.

And lastly, char c3 equals
exclamation point, in single quotes.

And now, let me just print this out.

I can't use %s because
that is not a string.

That's literally three chars, because
that's the design decision I made.

But I could do this--

%c, %c, %c, which we haven't seen
before, but %s is string, %i is int,

%c is, indeed, char.

So let me put a backslash n
at the end for cleanliness,

and now do, c1, c2, c3.

So this is like a char-based
version of printing string.

So let me make HI!

And then let me do ./hi, and it
looks like I used printf with %s.

But I did things very manually by
printing out each individual character.

What's cool now,
though, is that once you

know that characters are just numbers
and strings are just characters,

you can kind of poke around.

Let me change all three
placeholders to %i instead.

And this is totally fine, too.

Let me rerun this, make hi.

Actually, let me make one
change, just so we can see this.

Let me add spaces, just for aesthetics
sake, let me do make hi, ./hi, Enter,

and voila, like now, you can
actually see the numbers,

that I claimed back in week zero, were
in fact happening underneath the hood.

Well, this is not how
you would make strings.

It'd be incredibly tedious to have three
variables for three letter words, five

variables for five letter words.

We've been using, of course,
strings since last week,

so let's do that instead.

String s equals quote
unquote, double quotes "HI!"

For this, no, because of
these training wheels,

I need to include the CS50 library.

But we'll come back to
that in the coming weeks.

But for now, I'm going to go ahead and
create a string s called quote unquote,

"HI!"

And now I'm going to change
this to be my familiar %s,

and now just print out s itself.

This, of course, is the same
thing as last week, ./hi,

gives me the exact same thing, but now,
we're dealing, of course, with strings.

But how can we see a little beyond that?

Well, how about this?

Let's poke around further
with today's primitives.

Even though s is a string, I could
technically print out its first

character with %c by doing s[0].

I could technically print out its
second character with %c by doing s[1].

I could print out its third character
with %c and printing out s[2].

So again, this just derives
logically from my understanding

now that strings are
arrays, as you note.

Let me do make--

let me do make hi, ./hi.

And no visual change, but I'm
just kind of now tinkering around.

And in fact, if you're really
curious, let me do this.

Let me change these
back to i, back to i--

oops, back to i.

And let me add a fourth one
because if I'm really curious now,

let's see what's in s[3].

This is the fourth byte.

And even though the
string itself is H-I,

I think we can corroborate
this whole null thing.

Make hi, ./hi, Enter, and there it is.

You could have done this
last week, if you really

wanted to geek out on strings.

But for now, it's just revealing
what's going on underneath the hood.

Questions then, on
what these strings are?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Why do we need the bracket?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Why do
you not need brackets?

Good question.

Why do I not need brackets on line 6?

Because s is a string.

We'll see in a couple of
weeks that s is, essentially,

implemented underneath the
hood, indeed, as an array,

but that happens automatically for you.

You can treat s as just a variable
name without square brackets.

You will use square brackets
when you have arrays of ints

or you manually create arrays of chars
or doubles or floats or anything else.

But strings are special.

Why?

I mean, every program you write seems
to use strings, text in some form.

We're humans we like text,
not just numbers and such.

So this is just treated a little
specially in C and many other languages

as well.

Other questions on this here?

No?

Let's add then, one
other string to the mix.

So instead of just saying, HI!,
why don't we consider a version

of the program that
says both, HI! and BYE!.

And I claim now that
that backslash zero,

that null character is going
to be ever more important now

if we've got two strings
in memory, so that C knows

how to distinguish one from the other.

So let me go ahead and just get rid
of these two lines for the moment.

Let me recreate string s equals,
quote unquote double quotes, "HI!"

Let me give myself another one.

And because I'm just playing around,
I'll choose very short variable names.

String t equals quote unquote, "BYE!"

And then let me just
print them both out.

Let me go ahead and print
out %s, backslash n, comma s,

and then printf %s
backslash n, and then t.

So very simple demonstration
of just these two variables.

Make hi, ./hi, and of course, it prints
out two lines, one after the other.

What's actually going
on underneath the hood?

Well, let's go back to
the computer's memory.

HI!, I think, is going to be,
I claim, pretty much the same.

So s, I'll claim, is in the top
left, followed by the backslash zero.

And that's important now because BYE!
probably is going to end up there.

And visually, it wraps just by nature
of how I've drawn this grid of bytes,

but it's contiguous.

B-Y-E-!

null, A.K.A. backslash zero,
this is now helpful to printf

because now printf knows
where one begins and ends

by way of that special null character.

But we can poke around now, too.

What else can I do here?

How about this?

How about I go into my code here,
back to VS code, and let me go ahead

and say something like, well, if
I've got two of these strings,

you know, let's put them in an array.

Let's kind of do this sort of arrays in
arrays, sort of inception-style here.

So string words[2].

So give me an array
of two strings is what

I'm saying here in code, even though
we've not done it with strings yet.

We only did it with ints.

And now let me do this.

The first word A.K.A. words[0]
will equal, as before, HI!

And now words[1] will
equal quote unquote, "BYE!"

And now I've done the exact
same thing, but again, I'm

just avoiding having s, t, q, r, and all
these different variables in my code.

I just now am treating them as
one single array of strings.

How do I change my code down here?

Well, if I want to print the
first word, I do words[0].

And if I want to print the
second word, I do words[1].

This is not a useful
exercise at the moment

because I'm just making
my code more complicated.

But again, it allows us to
poke around and see what's

going on because there is that HI!

and BYE!.

But watch this.

If I really want to be
cool, I can do this.

Let's print out %c, %c, %c, backslash
n, and then here, %c, %c, %c, %c,

so four of those.

And now here's where
things get interesting.

Words is an array of strings.

Again, if I may, what's a string?

An array of characters.

So just use the same logic.

If words is an array of strings, you
get at the first string with words[0].

How do you get at the first
character in the first string?

Bracket 0, words[0][1],
and lastly, words[0][2].

And now down here, words[1], but
the first character is there.

Word[1], the second character is here.

Words[1], the third character is here--

whoops-- third character's here.

And words[1], the fourth
character is here.

This is not how people program.

This is only for demonstrations sake.

My God, it's so tedious
and verbose already.

But if I make hi now, ./hi, now,
I'm manually reinventing %s,

if I forgot it existed, using %c alone.

But you can indeed manipulate
arrays in this way.

But because strings are
arrays of characters,

you can manipulate
strings in this way too.

Any question now on this syntax?

Any questions here?

No?

No?

All right, well, let's
go ahead and propose

that we solve a couple of other
problems we might not have as before.

But first, a quick visual of what's
been going on underneath the hood here.

If here, again, is where we left
off on the screen, HI! and BYE!

back to back, here is really
how I just treated these things.

s bracket 0, 1, 2, 3 and
then t 0, 1, 2, 3, 4.

But really, once I put them in an
array, the picture becomes this.

Words[0] is the whole HI!.

Words[1] is the whole BYE!.

But if I really get into
the weeds and start indexing

into individual characters in
those strings, all I'm using

is new syntax in order to
represent these same values here.

Questions then, on these
representations before we forge ahead?

No?

Yeah?

AUDIENCE: Does the new line
character not [INAUDIBLE]??

DAVID MALAN: Does the new line
character-- say that once more?

AUDIENCE: Does the new line
character take up any space?

DAVID MALAN: Ah, really good question.

Does the new line character
take up any space?

It does, so far as printf is concerned.

But I'm not storing the
backslash n in my strings,

printf is being manually
handed that thing instead.

All right, so let's go
ahead then and consider

how we might solve some problems that
have arisen now with these strings,

as follows here.

Suppose I-- let's do this.

Let me go back to VS Code here.

And let me go ahead and open up a
new file called, how about, length.c.

And let's consider for a moment
how I might actually figure out

what the length of a string is, which
is distinct from the length of an array.

I claimed earlier, you cannot figure out
dynamically what the length of an array

is.

But I can figure out the length
of a string, specifically, because

of this implementation detail
of that null character.

So let me go ahead and do this.

Let me include cs50.h in
this second program here.

Let me include stdio.h, as before.

And let me do this, int main void--

and the first thing I'll do is
just get a string from the user.

I'll ask the user, as
always, for their name.

So I'll call getString, and say, what's
your name, question mark, as always.

And then down here, if I want to
figure out the length of this string

and print the length out
on the screen, well, I

can kind of do this similar
in spirit to the average,

where I'm accumulating something.

Let me go ahead and initialize N to 0.

Let me give myself--

it's not a for loop
because I don't have a--

I don't know in advance how long it is.

But what if I do this?

While the value at name[n]
does not equal '/0'--

crazy syntax at the moment,
but it's just the culmination

of these various building blocks.

Let me just finish
the thought here, n++.

And then down here, let's just
print out, with printf and %i,

that value of N. So I claim this is
going to show me the length of any

string I type in, whether it's hi
or bye or David or anything else.

I initialize a variable
to zero, and that's good

because that's where you
start counting in general.

While name[0] does not
equal backslash zero.

What is this saying?

Well, if name is the string the user
typed in-- and name is just an array,

as you noted--

the name[0] is going to
be the first character.

And I'm asking the question, well,
does the first character not equal

backslash zero?

And if I type in David, D, it's not,
so I keep going and I add 1 to N.

Then I'm going to check name[1].

Well, if I typed in David,
name[1] is going to be A.

A does not equal backslash zero, and
so it's going to go again and again

and again.

But five steps in total later,
it's going to get to the byte after

D-A-V-I-D, realize, wait a
minute, that is a backslash n.

The loop finishes, and I
print out the total length.

Arrays, in general, do not
have this null character.

However, strings do.

Again, strings are special versus
all of the other data types

we've talked about thus far.

But how could I, for
instance, do this differently?

Well, let's actually factor this out
as a function, as I've commonly done.

But rather than implement
it myself, you know what?

It turns out what's nice
about strings being so common,

there are many other people who
have solved these problems before.

And in fact, there's a
whole string library in C.

It is used by way of a
header file called string.h.

And what string.h is, is a library
of string-related functions.

In fact, you can see
in CS50's manual pages

for C, the string.h functions, at least
those that we recommend as most useful,

and in particular, if
you poke around there,

you'll see that there's
a function called strlen.

It means string length.

It was named very succinctly,
just because it's a little easier

to type than string length.

But strlen tells you
the length of a string.

So how might I use this in my code here?

Well, it turns out, I can
simplify this quite a bit.

Let me get rid of my loop,
get rid of my accounting

manually, and do something
like this-- int n

equals strlen of the humans name, name.

And now I'll just use printf,
as before, with %i backslash n,

and output the value of n.

But there's a bug at the moment.

What have I forgotten to do?

Yeah, I have to include the header
file at the top of the screen,

so let me-- at the top of the code.

So let me also include
string.h at the top of my file,

so that C knows that,
in fact, strlen exists.

Let me go ahead and
make length, as before.

./length-- or actually, really for
the first time, what's your name?

D-A-V-I-D. And hopefully,
I'm going to see, in fact, 5.

By contrast, if I run it again
and type in HI!, now I see three.

So strlen is just one of the
functions in that library.

And there are so many more.

In fact, yet another library that
might be useful moving forward

is this one, ctype,
which relates to C data

types and lots of functions
therein that can be useful.

For instance, if you review its
documentation in the manual pages

online, you'll see that
there are functions via which

we can solve problems like this.

Let me go ahead and propose here--

let me see.

Let's do an example here involving--

how about checking if something
is uppercase or lowercase,

and converting it to uppercase only.

Let me go back to VS Code, and
code a program called uppercase.c.

In this, file I'm going to start by
including now, as always, cs50.h.

I'm going to include stdio.h.

And I'm going to add one
other to the mix, which

is string.h now too, so I can access
the length of things as needed.

Int main void comes next.

And then within my main
function, I'm going

to go ahead and declare
a string called s.

I'm going to call getString, as before.

And I'm going to go ahead and just ask
the user for a string called before.

I want to do a before and after.

Whatever the user types in is before.

But I want to force everything
to uppercase, thereafter.

Let me now, in this loop here, do this.

Let me printf quote unquote, "After,"
just so we can see this on the screen.

And let me do four int i gets 0,
i is less than strlen of s, i++.

What am I about to do?

I'm about to iterate over
every character in the string

from left to right, from 0 on up to,
but not through, the length of s.

And how do I check if
something is lowercase,

so that I can actually
force it to uppercase?

Well, it turns out, I
could do this literally.

If the character in s at location i
is greater than or equal to capital A,

ampersand, ampersand, which means
and instead of or, which we saw

in the past, s[i] is less than
or equal to little z, that means,

logically in English, that
this is indeed lowercase.

How do I now convert it to
uppercase, this character?

Well, I could just literally
print out the same character.

But that would not be the answer here
because that's not changing the value.

But what could I do instead?

Well, let me actually pull up here
real fast the ASCII chart as before,

and let's see if we
can't glean some insight.

If I pull up the same
ASCII chart, and suppose

the human has typed in a
lowercase a, that's 97.

What letter-- I want to
convert it to uppercase

A, so what number do I want to
convert the 97 to, per week zero?

So 65, we keep coming back to that one.

What if the user types in lowercase b?

I want to change the 98
value to 66, and so forth.

And any quick math, how
far apart are those?

So it's always 32, like
uppercase to lowercase

is always, wonderfully, good
design, 32 away, one from the other.

So what does this mean?

Well, I think we saw earlier
that underneath the hood,

a char is just a number.

You can certainly do arithmetic on it.

And here, again, if you
understand these lower level

primitives, what if I do this?

Whatever s[i] is, if I know on
line 13 that it's lowercase,

do I want to add or subtract 32?

AUDIENCE: Subtract.

DAVID MALAN: So I want to subtract
because I want to go from like 97 to 65

or 98 to 66, so indeed, if you do
some quick math, that gives you 32.

So it's suffices to just treat
chars as numbers, subtract the 32,

and printing it with %c, I think, will
just convert lowercase to uppercase.

If you now fast forward to the real
world, Microsoft Word or Google Docs,

if you've ever chosen the menu option
that forces things to uppercase

or lowercase on occasion,
literally, that's

what Microsoft and Google have done.

They iterate over every character in
the document, check if it's lowercase,

and if so, they subtract 32 from
it and show you the new value.

What if, though, it is
not a lowercase letter?

I think I can keep it easy and just
print out the current letter unchanged,

if my goal is to simply force things
to all uppercase, and that letter,

then would be s[i].

So let me go ahead now and make
uppercase, hopefully, no errors.

./uppercase, and I'll now type
in David with an uppercase D,

but lowercase everything else.

But now the after version is DAVID--

an aesthetic bug.

Notice here, I forgot to include,
just for prettiness sake,

a backslash n at the end.

No problem, I'll add that.

Let me fix my mistake.

Make uppercase, ./uppercase, Enter.

D-A-V-I-D, Enter, and voila.

And I deliberately added
another space after,

just so they would line up
pretty, even though before

and after have different
numbers of letters.

Questions then, on this
implementation of forcing something

to uppercase, which in and of
itself is not all that enlightening,

but is representative now of how you
can leverage these low level primitives.

Question?

No?

All right, well, this
honestly is tedious.

My God, like does
Microsoft, Google, everyone,

you have to literally write out this
code just to do something simple?

Well, no, that's, again, why
we have things like libraries.

And increasingly now, for problem
sets, projects, and beyond,

well, you just use libraries
more often off-the-shelf

so as to solve problems that, surely,
other people have had before you.

So how can I now use
this library, ctype.h?

Well, let me go back into my code.

Let me include this among
my header files here.

Just so I can skim things easily,
I tend to alphabetize my headers.

But that's not strictly necessary, but
it allows me, at a glance, to realize,

did I or did I not
include something I need?

Now, let me go ahead and do this.

It turns out if you read the
documentation for the C type library,

there's a function,
wonderfully called, if islower,

that takes in a character as its
argument, essentially, so s[i].

And if that returns true, a
Boolean value, if you will,

well, I'm going to
force it to lowercase.

But I don't have to
do this math anymore.

Turns out, in the C type library,
there's also a function called to upper

that takes a character
as input, like s[i],

and it just does the math for you.

So that you can abstract
away the 32 thing,

and just know that someone else
has solved that problem for you.

Otherwise, I can leave my
code unchanged down below

because I'm not changing anything else.

So if I do make uppercase now,
and then ./uppercase, D-a-v-i-d,

with just a capital D,
and now it still works.

But if you read the documentation
further, it turns out that to upper

is smart.

If you pass in a character to
to upper, that's lowercase,

it obviously converts it to
uppercase by doing that math.

But if you pass in a character to
to upper that's already uppercase,

the documentation you would see tells
you that it leaves it unchanged.

So I can tighten all of this up.

I can get rid of the whole else.

I can get rid of the whole
if, and arguably now,

implement a program that's just
as correct, but better designed.

Why?

Fewer lines of code easier to read,
lower probability of mistakes,

assuming the library is correct.

It just makes it easier and
faster for me, now, to write code.

So if I now do, one last time,
make uppercase, Enter, ./uppercase,

and type in my name, still working.

But now notice, we've whittled this
down to far fewer lines of code,

albeit, using now this
additional library.

Questions then on how we did this?

Well, even though this
code, I daresay, is correct,

it's not necessarily
well-designed just yet.

In fact, there's one line
of code, one function

call in this current
implementation that's

more inefficient than it needs to be.

And allow me to draw your
attention to this here,

line 10, wherein we're calling strlen.

But we're calling it inside of
this for loop, specifically,

inside of the condition.

And why might that not
necessarily be the best idea?

Well, is the length of the
string as changing, ever?

I mean, certainly not within
the span of this loop.

And so here we are within our for
loop on line 10, 11, 12, and 13,

asking on every iteration
that same question.

What's the length of s?

What's the length of s?

What's the length of s?

And in turn, we're
calling strlen every time,

even though we're getting
back the same answer.

So I daresay a better
solution here would

be to maybe figure out the length
of s earlier on in my code,

and maybe declare a variable.

Or perhaps do something that's
syntactically a little more elegant,

and in fact, a very common
design in a loop like this,

would be to declare not
just one variable like i,

but to actually declare a second
variable called n, for instance, where

n is just some number, set
n equal to the length of s.

But thereafter, inside
of this condition,

instead of calling strlen of s again and
again and again, what might I now do?

I could instead just
compare i against n itself,

because n now will only be calculated
once when it's initialized,

just as i is initialize to zero.

And thereafter, we're going to be
comparing i, which is changing,

against n, which will not be.

So it's going to be marginally
more efficient by design.

Now with that said, a
good compiler could also

recognize that there is this
optimization possibility,

and maybe do it for us.

But for now, best to
get into the habit, best

to develop the muscle memory for
making those better design decisions

yourselves.

Questions, then, on how we did this?

No?

All right, a few final
building blocks for the day.

So we started by talking about those
command line arguments that clang uses,

whereby, anything after the command
that you type at a prompt, be it make

or clang or even CD in Linux,
any word thereafter, or something

cryptic like -o is a
command line argument.

It's an input to the command.

It's different from a function argument
because a function argument, of course,

is an input to a function.

But it's the same idea.

It's just different syntax after
the dollar sign at the prompt.

Well, it turns out that
command line arguments

are something you can now
use in your own programs

by accessing words after the prompt.

And let me propose that
we invent this as follows.

Let me propose that we
switch back to VS Code here,

and I'll open a new file
here called greet.c.

So in greet.c, it's going to be
a program that very simply greets

the user.

Had we written this last
week, we would have done this.

Include cs50.h, and then include
stdio.h, and then int main void,

and then we might do something simple
like string name equals getString,

quote unquote, "What's your name?"

And then we would have printed
out, as always, Hello, %s,

and then plugging in that name.

So this is the same program we've
implemented many times, just

to make sure it works--

although, nope, that's not
quite the same program.

Semicolon's in the wrong place.

This now is the same program.

So make greet, dot ./greet, and I'll
type in my own name. hello, David.

So we're back there.

Now, what's arguably a little
annoying about this program,

if I type in something
else like, Carter,

Enter, I have to run the program,
wait for the prompt, type in my name,

hit Enter.

And that's fine, but imagine if
every program worked like this.

Like make, suppose you could only
type make, then you wait for a prompt,

then you type the name of the program
you want to make, then you hit Enter.

Or worse, in Linux when you
have to change directories,

as you might have for problem set one,
what if you had to type CD, Enter,

now type the name of the folder
you want to change into, Enter--

I mean, it just slows life down.

And so it just gets annoying quickly.

So command line arguments just let you
express your whole thought all at once.

So how can I do this?

Well, if I want to express the notion
of command line arguments in my code,

I could do something like this.

I could, for the very
first time, go up and get

rid of this void, which as of today
means, this program takes no command

line arguments.

And I can change it to exactly this.

Int argc, string argv, with brackets.

Now it's cryptic, admittedly.

And let me zoom in.

But I think we can perhaps
infer now, what's going on.

If main now does not have
void as its input, which

means it takes no arguments,
surely, the spoiler

here is that now main will take
command line arguments somehow.

Any guesses as to what
argv is or will be?

What might this represent?

It's an array of strings,
right, by way of the syntax.

Yeah?

AUDIENCE: All the characters
will be typed out.

DAVID MALAN: Exactly.

It will be all of the characters,
or really all of the words

that you type at the prompt.

Argc, as an int, any guess?

Argument count is what it generally
stands for, though technically,

you could call these things anything.

But this is the convention.

Because I claimed earlier that arrays
don't keep track of their own length,

if you want to know how many words
the human typed at the prompt

after your program's
name, you have to be told,

not just the array of the words,
but the length of that array.

The strings, you can figure
out the length of using strlen,

but you can't figure out the length of
the array of strings, the collection

of words that the human typed in.

So how can I now use this?

Well, let me go ahead and do this.

Let me go ahead and change this program
now just to be printf, quote unquote,

"hello, %2 /n", then argv[1].

So this is not the best version
of my code yet, but it's my first.

Make greet, and now let me do
./greet, David all at once.

Enter, hello, David.

Now let me run it
again, ./greet, Carter.

Enter, hello, Carter.

It's a marginal improvement,
but I don't have

to wait for getString to
prompt me to hit Enter.

It's just speeding
things up, twice as fast.

One less command to type in.

But I deliberately did [1], but
what's the beginning of argv?

It would be [0].

Well, what's that?

This is sometimes useful,
though for now, it's not.

Suppose I recompile my code and
run this program now, greet David.

Anyone want to guess what's in argv[0]?

AUDIENCE: [INAUDIBLE]

DAVID MALAN: Say again?

AUDIENCE: Greet, hello.

DAVID MALAN: Greet,
Enter, hello, ./greet.

So if you want to sort of inception
style your program to figure out what

its own name is, or at least how it
was executed at the command line,

at the terminal, you
can look at argv[0].

In general, probably not
that useful, probably better

to start looking at [1], which was
the first word after the program name.

And if there were more, I could
do this how about argv[2],

let me add in a second %s.

Let me recompile greet.

Let me do ./greet David Malan,
Enter, and that, too, now works,

taking in two words at the prompt.

If I really want to
be smart at this now,

I could do something like this, though.

How about if the count of
arguments, A.K.A. argc,

equals equals to, then assume that the
human typed in only their first name,

and do printf hello comma
%s /n, and then argv[1].

Else, if the human did
not provide exactly two

arguments, the name of the
program and their own name,

let's just print out a default
value, lest they forgot their name

or they typed in two
names or three names.

Let's just do, hello
comma world as a default.

And we'll just ignore
what the human typed in.

If I recompile this, make greet, I
can do ./greet and David again, Enter.

Oops-- sorry, what am I missing?

Yeah, so newbie mistake.

Else, all right, make greet again.

./greet, David, Enter,
there's my hello, David.

But if I omit my name, I just get
the generic, like a default value.

And if I get a little curious and I type
in both names, then I get ignored too.

Why?

Because I just haven't built
in support for argc of three.

I could do anything I want,
but now we have access

to these kinds of building blocks.

All right, what else might I do here?

Well, it turns out there might be some
final features for us to now execute.

Notice, though, that
in C, despite what you

might see in books or
online tutorials, nowadays,

the two official formats
for defining a main function

are either this, which we've been using
now for two plus weeks or now this,

whereby, you change
the void to int argc,

and then for now, string
argv, and then empty brackets.

And we'll see that this, too, is
a simplification, some training

wheels if you will.

But for now, those are
the two forms, even

though you will see in online
tutorials and even books, some people

use main in different ways.

These are the two now to keep in mind.

And I'll note that these
command line arguments

are kind of all over the place.

Didn't probably expect to see
this word on the screen here.

And what does it mean?

Well, it turns out that
for decades-- there's

actually this program that
comes with Linux systems

in particular called cowsay.

Why?

Probably because someone had too
much free time once and decided

to write a program that creates ASCII
art out of a cow saying something

textually on the screen.

But you use cowsay, just for fun,
by way of command line arguments.

So for instance, let me propose
that I go back to VS Code

here, not because I
want to write any code,

but I just want to use
my terminal window.

And let me maximize my
terminal window here.

And let me go ahead and type in
something like, how about cowsay,

space moo?

So cowsay is not a program I wrote.

It's been around for decades.

But we installed it in VS
Code for you in the cloud.

It takes at least one
command line argument.

What do you want the cow to say?

I can say, cowsay moo, and
hit Enter, and voila, there

is my ASCII art of a cow
saying moo on the screen.

It can say multiple words.

So I can say, Hello, world, Enter.

And now it says, Hello, world.

So this is just an example of a
silly program that uses command line

arguments, but it takes others too.

Just like clang, use this
convention of hyphens

to change the output of the program.

Dash something is just a super common
convention with command line arguments

when you want a very terse notation
for some option like output.

In cowsay, I read the
documentation, and it turns out

there's a dash f command
line argument that

allows you to change the
appearance of the cow, if you will.

So if I do cowsay dash f, duck, and
then some other word like quack,

it's no longer a cow.

That command line argument turns it
into a tiny, adorable duck instead.

And then lastly, just for fun,
because I spent way too much time

playing with command line arguments.

Cowsay dash f, dragon, and
then how about, rawr, Enter,

you can even get this
on the screen here.

So this, too, is just
an example of what you

can do with these command line arguments
now that we have this building block.

And there's one final thing
we can now do with code.

There's one last
feature today that we'll

introduce before we now
connect all of these dots

to readability and encryption by
talking, lastly, about something called

exit status.

It turns out that whenever
your main function exits,

it returns a secret integer
that you can figure out,

as the programmer or an
advanced user, what it was.

And these exit codes, exit statuses,
are typically used to indicate errors.

So for instance, over the past
couple of years, if you've used zoom

and you ever got some kind of error,
you might have seen a screen like this.

It's usually not that helpful,
maybe tells you to click

Report Problem or Contact Support.

But very often in our human
world on Macs, PCs, and phones,

you see cryptic error codes,
like literally numbers

that probably only Zoom knows, or
Microsoft or Google or whatever company

wrote the software you're using.

But that number corresponds
to a specific error

that some human somewhere
knows might very well happen.

These are used similarly,
although under a different name

that we'll talk about later in
the term, on the web as well.

Have you ever seen this-- maybe
not character, but number?

So, 404 means what?

AUDIENCE: Error.

DAVID MALAN: So error,
yes, but really, not found.

So, why?

I mean, this is the most arcane thing.

And we'll talk in a few weeks about
what this and other numbers mean,

but numbers are all
around us in technology,

and they very often mean something
to the technical people who

wrote the software, less so
to humans like you and me.

Why so many of us recognize
404 is kind of weird,

that like that's been around
long enough that we all know it.

But it really is just a special number
that represents an error of some sort.

So it turns out, the last
thing we'll reveal today

about what we've been taking
for granted for two weeks,

is what the int is in main.

We've seen, just a moment ago, that
the thing in the parentheses, which

up until now has been void, which
means no command line arguments.

now int argc string argv brackets just
means, yes, command line arguments.

And we've seen how to access them.

So the last piece of
the puzzle, honestly,

of all the cryptic syntax the past
two weeks, is just what int means.

Int is always there for
main, and it indicates

that main will always return an integer,
even though you and I have never

done so explicitly.

Usually, main returns
0, by default. But it

would be weird if you saw an error
message saying 0, so 0 is just hidden.

You would never see it on the screen.

But it's happening automatically
by way of how C is designed.

So let me write one final program here.

I'll call it, for instance, status.c
to show you these exit statuses.

Code of status.c, and then up here,
let me do something simple like include

cs50.h, then include
stdio.h, and then int main--

actually, let's use a command line
argument. int argc, string argv[],

so that's copy, paste.

But now let's do this.

If argc does not equal to--

why don't we do something like this?

Let's not just default to
hello, world like last time.

Let's yell at the user.

So let's say something like printf
missing command line argument,

so that they know they
screwed up and they need

to run the program again correctly.

Else, let's go ahead and say, print
out, as before, Hello, comma %s,

and then plug in argv[1], so the
human's name from the prompt.

Now at this point, let me go
ahead and run status, ./status,

and I'll type nothing first.

I get yelled at.

This time, I'll type it again.
./status David, and it works properly.

But now let me show you a
somewhat secret, cryptic command.

You can type this at your prompt,
and it's just a coincidence

that there's another dollar sign.

Echo $?, totally arcane,
but it allows you

to see what exit status
your program has ended with.

So let me run this again the wrong way.

./status, I get the error message.

What was secretly returned?

I can't see it.

There's obviously no error
screen, but by typing echo $?,

I can see that, oh, my program
automatically, by default, returns

zero.

However, if I run it again
correctly, ./status David, Enter,

this is the correct version.

But if I run echo $?

status again, it's still entered with 0.

And long story short, this
is just a missed opportunity.

When something goes wrong, why
don't I return a value other than 0?

0, by default, means success.

And it's always there automatically.

But you can control this.

I can go into my code here and return
1, else, if something works fine,

I can return 0, by default. And
honestly, if I omit the return zero,

again, zero automatically is returned.

So let me go ahead and go be explicit,
just so I know what's going on.

Make status again, ./status, and
let's do this correctly with David.

Enter, hello, David.

Echo $?, zero.

So all is well.

But now if I do ./status and nothing,
or multiple things, but not just David,

Enter, I get the error message.

But now if I do echo $?,
voila, there now is the one.

So what does this now mean?

This is, in the graphical
world, we would just

show something like this
on the screen, which is

a little more informative to the user.

But even in the Linux world
where you don't have a GUI,

necessarily, even for the
programs we've written,

you can check these exit statuses.

And in fact, more comfortable,
more advanced programmers,

when they write code
that calls programs,

be it cowsay or anything
else, you can encode,

check what the exit status is
of a program, and then decide,

did my program work or did it not?

And now let's connect
the final dots before we

adjourn for some fruit snacks.

Cryptography, namely one of
the applications this week

via which you'll be able
to send, if you will,

secret messages, and better
yet, decrypt secret messages.

This will be in addition
to perhaps analyzing

the readability of text
using heuristics, like we

identified at the start of class two.

So cryptography is just the art, the
science of encrypting information,

scrambling information so that
if you have a secret message

to send in so-called plaintext, you
can run it through some algorithm

and turn it into what's called
ciphertext, thereby, encrypting it.

And only someone who knows
what algorithm you've used

and what input you've used to
the algorithm, theoretically,

can decrypt that process and convert
it back to the original message.

So if we use our mental model
from last week, here is a problem.

Here is an input and output.

The goal I claim here is to take
some plain text, like the message

you want to send, think
back to grade school

if you ever passed a note to a friend
or to your crush saying, I love you,

it's a little awkward if the teacher
or someone else intercepts the paper.

And in English, it just says,
I love you, or whatever it is.

It'd be nice if you had at
least encrypted it in some way.

But the other person needs to
know what algorithm you used

and what inputs you
use to that algorithm

so that, ultimately, they can decode
the so-called ciphertext, which

is the output.

So what goes inside of the box today?

Well, an algorithm, as it relates
to cryptography, is called a cipher.

And a cipher is a fancy name for
an algorithm that encrypts text

from plaintext to ciphertext.

The catch is, there needs to
be not just the algorithm,

there needs to be an input to it.

And so, for instance, you might draw
the picture like this for the first time

today.

And we've seen this in code.

You can give multiple inputs
or arguments to functions.

So in this black box, can you
imagine passing in the message

you want to send, and then some secret.

So for instance, suppose
that, the simplest

thing I could think of as a kid was
instead of sending the letter A,

why don't I write the letter B?

Instead of the letter B, why
don't I write the letter C?

So I can kind of shift the
English alphabet by one space.

So A becomes B, B
becomes C, dot, dot, dot,

Z becomes A. You can
wrap around at the end.

And let's assume no punctuation
in this part of the story.

So that's a very simple algorithm--
add a value to each letter

and send the value as the ciphertext.

And now the teacher, the classmate,
they have to know that you use,

not only this rotational algorithm,
also known as a Caesar cipher,

they also need to know
what number you use.

Did you add 1 to every letter, 2 to
every letter, 25 to every letter?

Now if they're super smart and probably
not the young age in this story,

they could also just
try all possibilities.

And that would be an
attack on the algorithm.

This is not a sophisticated
algorithm, but it's

enough to send a message in class.

So if the two inputs now are HI!

as the plain text message, and 1 as
the so-called key, the secret number

that only you and the
other person know, you

might be able to encrypt a
message from one way to the other.

And so in this case, for instance, HI!

would become I-J-!.

In this version of the
algorithm, we're not

going to bother with
numbers or punctuation.

We'll only operate on A through
Z, be it uppercase or lowercase.

So now if you were to receive a slip
of paper in class with I-J on it,

you, the recipient,
would know what it is

so long as you know that
the sender used one,

because you just reverse the algorithm
and you subtract one instead.

The teacher, they probably
don't know what this means,

and they're not going to spend
time hacking the message,

so it just looks scrambled to them.

And that's what we get from encryption.

Someone who intercepts it, be it
in class or in the real world,

on the internet or anywhere else,
can't actually figure out, ideally,

what it is you have sent.

The opposite, of course, is
indeed called decryption,

but the process is the same.

We now pass in negative 1.

And so how about this?

Why don't we end with
a demonstration here?

UIJT XBT DT50-- there's
a bit of a tell there.

If we pass that in and
do negative 1, well,

how do we get out the
plaintext originally?

Well, if this is the ciphertext,
and we subtract 1 from each letter,

I think U becomes T, I becomes H, J
becomes I, T becomes S, X becomes W,

B becomes A, T becomes S, D becomes C,
T becomes S, and this was, indeed, CS50.

Have a duck on your way out,
and some snacks in the lobby.

[APPLAUSE]

[FILM ROLLING]

[MUSIC PLAYING]