DAVID J. MALAN: All right.

This is CS50 and this is the start of week two.

And you'll recall that over the past couple of weeks,

we've been building up.

First initially from Scratch, the graphical programming language

that we then, just last week, translated to the equivalent program NC.

And of course, there's a lot more syntax now.

It's entirely text but the ideas, recall, were fundamentally the same.

The catch is that computers don't understand this.

They only understand what language?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: zeros and ones or binary.

And so there's a requisite step in order for us to get from this code to binary.

And what was that step or that program or process called?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, so compiling.

And of course, recall as you've now experimented

with this past week that to compile a program,

you can use clang for C, language.

And you can just say clang and then the name of the file

that you want to compile.

And that outputs by default a pretty oddly named program.

Just a dot out.

Which stands for assembler output.

More on that in just a moment.

But recall too that you can override that default behavior.

And you can actually say, Output instead a program

called, hello instead of just a dot out.

But you can go one step further, and you actually use Make.

And Make it self is not a compiler, it's a build utility.

But in layman's terms, what does it do for us?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: compiles it.

And it essentially figures out all of those otherwise cryptic

looking command line arguments.

Like dash-o something, and so forth.

So that the program is built just the way

we want it without our having to remember

those seemingly magical incantations.

And though that only works for programs as simple as this.

In fact, some of you with the most recent problems that

might have encountered compilation errors that we actually

did not encounter deliberately in class because Make was helping us out.

In fact, as soon as you enhance a program

to actually take user input using CS50's library by including CS50 dot H,

some of you might have realized that all of a sudden the sandbox,

and more generally Clang, didn't know what get_string was.

And frankly, Clang might not even known what a string was.

And that's because those two are features of CS50's library

that you have to teach Clang about.

But it's not enough to teach Clang what they look like, as by including CS50.h.

Turns out there's a missing step that Make helps us solve

but that you too can just solve manually if you want.

And by that I mean this, instead of compiling a program with just Clang,

hello.c.

When you want to use CS50's library, you actually

need to add this additional command line argument.

Specifically at the end, can't go in the beginning like dash-O.

And dash-L stands for link.

And this is a way of telling Clang, by the way when compiling my program,

please link in CS50's zeros and ones that we the staff

wrote some weeks ago and installed in the sandbox for you.

So you've got your zeros and ones and then

you've got our zeros and ones so to speak.

And dash-LCS50 says to link them together.

So if you were getting some kind of undefined reference error to get_string

or you didn't--

you weren't able to compile a program that just used any of the get functions

from CS50's library.

Odds are, this simple change dash-LCS50 would have fixed.

But of course, this isn't interesting stuff to remember, let alone

remembering how to use dash-0 as well, at which point

the command gets really tedious to type.

So here comes, Make again.

Make automates all of this for us.

And in fact, if you henceforth start running Make and then

pay closer attention to the fairly long line of output that it outputs,

you'll actually see mention of dash-LCS50,

you'll see mention of even dash-LM, which stands for math.

So if you're using round, for instance, you

might have discovered that round two also

doesn't work out of the box unless you use Make itself

or this more nuanced approach.

So this is all to say that compiling is a bit of a white lie.

Like, yes you've been compiling and you've been going from source code

to machine code.

But it turns out that there's been a number of other steps happening

for you that we're going to just slap some labels on today.

At the end of the day, we're just breaking the abstraction.

So compiling is this abstraction from source code to machine code.

Let's just kind of zoom in briefly to appreciate

what it is that's going on in hopes that it makes the code we're

compiling a little more understandable.

So step one of four, when it comes to actually compiling a program

is called Pre-processing.

So recall that this program we just looked at had a couple of

includes at the top of the file.

These are generally known as pre-processor directives.

Not a particularly interesting term but they're

demarcated by the hash at the start of these lines.

That's a signal to Clang that these things should be handled first.

Preprocessed.

Process before everything else.

And in fact, the reason for this we did discuss last week, inside of CS50.h

is what, for instance?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Specifically, the declaration of get strings.

So there's some lines of code, the prototype if you recall,

that one line of code that teaches Clang what the inputs to get_string are

and what the outputs are.

The return type and the arguments, so to speak.

And so when you have include CS50.h at the top of the file, what

is happening when you first run Clang during this so-called pre-processing

step, is Clang looks on the hard drive for the file literally called CS50.h.

It grabs its contents and essentially finds and replaces this line here.

So somewhere in CS50.h is a line like this yellow one here

that says get_string, is a function that returns a string.

And it takes as input, the so-called argument, a string

that we'll call prompt.

Meanwhile, with include standard I/O. What's the point of including that?

What is declared inside of that file presumably?

Yeah?

AUDIENCE: It's the standard inputs and outputs.

DAVID J. MALAN: Standard inputs and outputs.

And more specifically, what example there of?

What function?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: So printf.

The other function we keep using.

So inside of standard io.h, somewhere on the sandbox's hard drive

is similarly a line of code that frankly looks a little more cryptic

but we'll come back to this sort of thing

down the road, that says print if is a function.

Happens to return on int, but more on that another time.

Happens to take a char* format.

But more on that another time.

Indeed, this is one of the reasons we hide

this detail early on because there's some syntax that's

just a distraction for now.

But that's all that's going on.

The sharp include sign is just finding and replacing the contents.

Plus dot, dot, dot, a bunch of other things in those files as well.

So when we say pre-processing, we just mean

that that's getting substituted in so you don't have to copy and paste

this sort of thing manually yourself.

So "compiling" is a word that actually has a well-defined meaning.

Once you've preprocessed your code, and your code looks essentially like this,

unbeknownst to you, then comes the actual compilation step.

And this code here gets turned into this code here.

Now this is scary-looking, and this is the sort of thing

that if you take a class like CS61 at Harvard,

or, more generally, systems programming, so to speak,

you might see something like this.

This is x86 64-bit assembly instructions.

And the only thing interesting about that claim for the moment

is that assembly--

I kind of alluded to that earlier-- assembler output, a.out.

There's actually a relationship here, but long story short, these

are the lower level instructions that only the CPU,

the brain inside your computer, actually understands.

Your CPU does not understand C. It doesn't understand Python or C++

or Java or any language with which you might be familiar.

It only understands this cryptic-looking thing.

But frankly, from the looks of it, you might glean that probably not so much

fun to program in this.

I mean, arguably, it's not that much fun to program yet in C,

So this looks even more cryptic.

But that's OK.

C and lots of languages are just these abstractions

on top of the lower level stuff that the CPUs do actually

understand so that we don't have to worry about it as much.

But if we highlight a few terms, here you'll see some familiar things.

So main is mentioned in this so-called assembly code.

You see mention of get string and printf,

so we're not losing information.

It's just being presented in really a different language, assembly language.

Now you can glean, perhaps, from some of the names of these instructions,

this is what Intel Inside means.

When Intel or any brand of CPU understands instructions,

it means things like pushing and moving and subtracting and calling.

These are all low level verbs, functions,

if you will, but at the level of the CPU.

But for more on that, you can take entire courses.

But just to take the hood off of this for today,

this is a step that's been happening for us magically unbeknownst

to us, thanks to Clang.

So assembling-- now that you've got this cryptic-looking code that we will never

see again-- we'll never need to output again--

what do you do with it?

Well, you said earlier that computers only understand zeros and ones,

so the third step is actually to convert this assembly language to actual zeros

and ones that now look like this.

So the assembling step happening, unbeknownst to you,

every time you run Clang or, in turn, run

make, we're getting zeros and ones out of the assembly code,

and we're getting the assembly code out of your C-code.

But here's the fourth and final step.

Recall that we need to link in other people's zeros and ones.

If you're using printf you didn't write that.

Someone else created those zeros and ones, the patterns

that the computer understands.

You didn't create get string.

We did, so you need access to those zeros and ones

so that your program can use them as well.

So linking, essentially, does this.

If you've written a program-- for instance, hello.c--

and it happens to use a couple of other libraries,

files that other people wrote of useful code

for you, like cs50.c, which does exist somewhere,

and even stdio.c, which does exist somewhere,

or technically, Standard IO is such a big library,

they actually put printf in a file specifically called printf.c.

But somewhere in the sandbox's hard drive, in all of our Macs and PCs,

if they support compiling, are, for instance, files like these.

But we've got to convert this to zeros and ones, this, and this,

and then somehow combine them.

So pictorially, this just looks a bit like this.

And this is all happening automatically by Clang.

Hello.c, the code you wrote, gets compiled

to assembly, which then gets assembled into zeros and ones, so-called machine

code or object code.

Cs50.c-- we did this for you before the semester started.

Printf was done way before any of us started decades

ago and looks like this.

These are three separate files, though, so the linking step literally