字幕表 動画を再生する 英語字幕をプリント [MUSIC PLAYING] DAVID J. MALAN: All right, this is CS50 and this is a lecture four. So we're here in beautiful Lowell Lecture Hall and Sanders is in use today. And we're joined by some friends that will soon be clear and present in just a moment. But before then, recall that last time we took a look at CS50 IDE. This was a new web-based programming environment similar in spirit to CS50 Sandbox and CS50 Lab, but added a few features. For instance, what features did it add to you-- to your capabilities? Yeah? AUDIENCE: Debugger. DAVID J. MALAN: What's that? AUDIENCE: The debugger. DAVID J. MALAN: The debugger. So debug50, which opens that side panel that allows you to step through your code, step by step, and see variables. Yeah? AUDIENCE: Check50. DAVID J. MALAN: Sorry, say again? AUDIENCE: Check50. DAVID J. MALAN: Check50 as well, which is a CS50 specific tool that allows you to check the correctness of your code much like the teaching fellows would when providing feedback on it. Running a series of tests that pretty much are the same tests that a lot of the homework's will encourage you yourself to run manually, but it just automates the process. And anything else? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: So that is true too. There's a little hidden Easter egg that we don't use this semester, but yes indeed. If you look for a small puzzle piece, you can actually convert your C code back to Scratch like puzzle pieces and back and forth, and back to forth, thanks to Kareem and some of the team. So that is there, but by now, it's probably better to get comfortable with text as well. So there's a couple of our other tools that we've used over time of course besides check50 and debug50. We've of course used printf and when is printf useful? Like when might you want to use it beyond needing to just print something because the problem set tells you to. Yeah? AUDIENCE: To find where your bug is. DAVID J. MALAN: Yeah, so to find where your bug is. If you just, kind of, want to print out variables, value or some kind of text so you know what's going on and you don't necessarily want to deploy debug50, you can do that. When else? AUDIENCE: If you have a long formula for something [INAUDIBLE] and you want to see [INAUDIBLE]. DAVID J. MALAN: Good. Yeah. AUDIENCE: How running-- like going through debug50 50 times. DAVID J. MALAN: Indeed. Well, in real life-- so you might want to use printf when you have maybe a nested loop, and you want to put a printf inside loop so as to see when it kicks in. Of course, you could use debug50, but you might end up running debug50 or clicking next, next, next, next, next, next, next so many times that gets a little tedious. But do keep in mind, you can just put a breakpoint deeper into your code as well and perhaps remove an earlier breakpoint as well. And honestly, all the time, whether it's in C or other languages, do I find myself occasionally using printf just to type out printf in here just so that I can literally see if my code got to a certain point in here to see if something's printed. But the debugger you're going to find now and hence forth so much more powerful, so much more versatile. So if you haven't already gotten to the habit of using debug50 by all means start and use those breakpoints to actually walk through your code where you care to see what's going on. So style50, of course, checks the style of your code much like the teaching fellows might, and it shows you in red or green what spaces you might want to delete, what spaces you might want to add just to pretty things up. So it's more readable for you and others. And then what about help50? When should you instinctively reach for help50? AUDIENCE: When you don't understand an error message. DAVID J. MALAN: Exactly. Yeah, when you don't understand an error message. So you're compiling something. You're running a command. It doesn't really quite work and you're seeing a cryptic error message. Eventually, you'll get the muscle memory and the sort of exposure to just know, oh, I remember what that means. But until then, run help50 at the beginning of that same command, and it's going to try to detect what your error is and provide TF-like feedback on how to actually work around that. You'll see two on the course's website is a wonderful handout made by Emily Hong, one of our own teaching fellows, that introduces all of these tools, and a few more, and gets you into the habit of thinking about things. It's kind of a flow chart. If I have this problem, then do this or else if I have this problem do this other thing. So to check that out as well. But today, let's introduce really the last, certainly for C, of our command line tools that's going to help you chase down problems in your code. Last week, recall that we had talked about memory a lot. We talked about malloc, allocating memory, and we talked about freeing memory and the like. But it turns out, you can do a lot of damage when you start playing with memory. In fact, probably by now, almost everyone-- segmentation fault? [LAUGHTER] Yeah, so that's just one of the errors that you might run into, and frankly, you might have errors in your code now and hence forth that have bugs but you don't even realize it because you're just getting lucky. And the program is just not crashing or it's not freezing, but this can still happen. And so Valgrind is a command line program that is probably looks the scariest of the tools we've used, but you can also use it with help50, that just tries to find what are called memory leaks in your program. Recall that last week we introduced malloc, and malloc lets you allocate memory. But if you don't free that memory, by literally calling the free function, you're going to constantly ask your operating system, MacOS, Linux, Windows, whatever, can I have more memory? Can I have more memory? Can I have more memory? And if you never, literally, hand it back by calling free your computer may very well slow down or freeze or crash. And frankly, if you've ever had that happen on your Mac or PC, very likely that's what some human accidentally did. He or she just allocated more and more memory but never really got around to freeing that memory. So Valgrind can help you find those mistakes before you or your users do. So let's do a quick example, let me go CS50 IDE, and let me go ahead and make one new program here. We'll call it memory.c because we'll see later today how I might chase down those memory leaks. But for now, let's start with something even simpler, which all of you may be done by now, which is to accidentally touch memory that you shouldn't, changing it, reading it and let's see what this might mean. So let me do the familiar at the top here. Include standard IO. Well, let's not even do that yet. Let's just do this first. Let's do int, main(void), just to start a simple program and in here let me go ahead and just call a function called f. I don't really care what its name is for today. I just want to call a function f, and then that's it. Now this function f, let me go ahead and define it as follows, void f(void). It's not going to do much of anything at all. But let's suppose, just for the sake of discussion, that f's purpose in life is just to allocate memory for whatever useful purpose, but for now it's just for demonstration's sake. So what's the function with which you can allocate memory? AUDIENCE: Malloc. DAVID J. MALAN: Malloc. So suppose I want malloc space for, I don't know, something simple like just one integer. We're just doing this for demonstration purposes, or actually let's do more, 10 integers, 10 integers. I could, of course, do-- well, give me 10, but how many bytes do what I want? How many bytes do I need for 10 integers? AUDIENCE: sizeof(int). DAVID J. MALAN: Yeah, so I can do literally sizeof(int) and most likely the size of an int is going to be? AUDIENCE: Four. DAVID J. MALAN: Four, probably. On many systems today, it's just 4 bytes or 32 bits, but you don't want to hard code that lest someone else's computer not use