week 3 part i

75
Week 3 Part I Kyle Dewey

Upload: ulric-delaney

Post on 03-Jan-2016

27 views

Category:

Documents


0 download

DESCRIPTION

Week 3 Part I. Kyle Dewey. Overview. Odds & Ends Constants Errors Functions Expressions versus statements. Pre-Lab. Underflow & Overflow Note. Constants. Constants. Values which never change Specific values are constants 55 27.2 ‘a’ “foobar”. Constants. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Week 3 Part I

Week 3 Part IKyle Dewey

Page 2: Week 3 Part I

Overview

•Odds & Ends

•Constants

•Errors

•Functions

•Expressions versus statements

Page 3: Week 3 Part I

Pre-Lab

Page 4: Week 3 Part I

Underflow & Overflow Note

Page 5: Week 3 Part I

Constants

Page 6: Week 3 Part I

Constants

•Values which never change

•Specific values are constants

•55

•27.2

•‘a’

•“foobar”

Page 7: Week 3 Part I

Constants

•Specifically in the program text

•Constant in that 52 always holds the same value

•We cannot redefine 52 to be 53

Page 8: Week 3 Part I

Symbolic Constants

•Usually when programmers say “constant”, they mean “symbolic constant”

•Values that never change, but referred to using some symbol

•i.e. π (pi - 3.14...)

•Mapping between symbol and value is explicitly defined somewhere

Page 9: Week 3 Part I

In C

•Use #define

•By convention, constants should be entirely in caps

#define PI 3.14...int x = PI * 5;

Page 10: Week 3 Part I

Mutability

•Constants are, well, constant!

•Cannot be changed while code runs

#define PI 3.14...PI = 4; // not valid C!

Page 11: Week 3 Part I

What #define Does

•Defines a text substitution for the provided symbol

•This text is replaced during compilation by the C preprocessor (cpp)

Page 12: Week 3 Part I

Example #1

#define PI 3.14...int x = PI * 5;

Code

int x = 3.14 * 5;After

Preprocessor

Page 13: Week 3 Part I

Example #2

Code

3.14 = 4;After

Preprocessor

#define PI 3.14...PI = 4;

Page 14: Week 3 Part I

Best Practices

•Generally, all constants should be made symbolic

•Easier to change if needed later on

•Gives more semantic meaning (i.e. PI is more informative than 3.14...)

•Possibly less typing

Page 15: Week 3 Part I

Errors

Page 16: Week 3 Part I

Errors•Generally, expected result does not

match actual result

•Four kinds of errors are relevant to CS16:

•Syntax errors

•Linker errors

•Runtime errors

•Logic errors

Page 17: Week 3 Part I

Errors

•Four kinds of errors are relevant to CS16:

•Syntax errors

•Linker errors

•Runtime errors

•Logic errors

Page 18: Week 3 Part I

Syntax Error

•A “sentence” was formed that does not exist in the language

•For example, “Be an awesome program” isn’t valid C

Page 19: Week 3 Part I

Syntax Error

•Easiest to correct

•Compiler will not allow it

•*Usually* it will say where it is exactly

Page 20: Week 3 Part I

On Syntax Errors

•...sometimes the compiler is really bad at figuring out where the error is

#include <stdio.h>int main() { printf( "moo" ) printf( "cow" ); return 0;}

Page 21: Week 3 Part I

Reality

#include <stdio.h>int main() { printf( "moo" ) printf( "cow" ); return 0;}

•Missing semicolon at line 4

Page 22: Week 3 Part I

GCC

#include <stdio.h>int main() { printf( "moo" ) printf( "cow" ); return 0;}

syntax.c: In function ‘main’:syntax.c:5: error: expected ‘;’ before ‘printf’

Page 23: Week 3 Part I

Ch

#include <stdio.h>int main() { printf( "moo" ) printf( "cow" ); return 0;}

ERROR: multiple operands together ERROR: syntax error before or at line 5 in file syntax.c ==>: printf( "cow" ); BUG: printf( "cow" )<== ???

Page 24: Week 3 Part I

The Point

•Compilers are just other programs

•Programs can be wrong

•Programs are not as smart as people

Page 25: Week 3 Part I

Errors

•Four kinds of errors are relevant to CS16:

•Syntax errors

•Linker errors

•Runtime errors

•Logic errors

Page 26: Week 3 Part I

Recall Linking

1: somethingFromHere();2: somethingFromElsewhere();3: somethingElseFromHere();

somethingFromHere

somethingElseFromHere

somethingFromElsewhere

Page 27: Week 3 Part I

Recall Linking

somethingFromHere

somethingElseFromHere

somethingFromElsewhere

Page 28: Week 3 Part I

Linker Errors

•What if somethingFromElsewhere is nowhere to be found?

•Missing a piece

•Cannot make the executable

Page 29: Week 3 Part I

Example

int something();int main() { something(); return 0;}

•int something(); tells the compiler that something exists somewhere, but it does not actually give something

Page 30: Week 3 Part I

Example

int something();int main() { something(); return 0;}

Undefined symbols for architecture x86_64: "_something", referenced from: _main in ccM6c8aW.old: symbol(s) not found for architecture x86_64

Page 31: Week 3 Part I

Errors

•Four kinds of errors are relevant to CS16:

•Syntax errors

•Linker errors

•Runtime errors

•Logic errors

Page 32: Week 3 Part I

Runtime Errors

•Error that occurs while the code is running

•Compilation and linking must have succeeded to get to this point

Page 33: Week 3 Part I

Examples

•Overflow

unsigned char x = 255;x = x + 1;

•Underflow

unsigned char x =0;x = x - 1;

Page 34: Week 3 Part I

Examples•Divide by zero (especially for

integers!)

unsigned int x = 5 / 0;

•Wrong printf placeholder

printf( “%s”, 57 );

Page 35: Week 3 Part I

Errors

•Four kinds of errors are relevant to CS16:

•Syntax errors

•Linker errors

•Runtime errors

•Logic errors

Page 36: Week 3 Part I

Logic Errors

•It works!

•...but it doesn’t do what you wanted

•Like getting the wrong order at a restaurant

Page 37: Week 3 Part I

Examples

•Transcribed an equation incorrectly

•Using the wrong variable

•Lack of understanding of problem

•etc. etc. etc...

Page 38: Week 3 Part I

Logic Errors

•By far, the most difficult to debug

•It might be done almost correctly

•This is why testing is so important!

Page 39: Week 3 Part I

FunctionsDivide and Conquer Revisited

Page 40: Week 3 Part I

Divide and Conquer

•Break a problem down into distinct subproblems, solve them individually, and finally combine them

Page 41: Week 3 Part I

Divide and Conquer

ProgramProgram

Input

Output

Page 42: Week 3 Part I

Divide and Conquer

SubprograSubprogram 1m 1

Input

OutputSubprograSubprogra

m 2m 2

Output / Input

Page 43: Week 3 Part I

Divide and Conquer

Input

OutputSubprograSubprogra

m 2m 2

Subprogram Subprogram AA

Subprogram Subprogram BB Output / Input

Page 44: Week 3 Part I

Input and Output•Intentionally left ambiguous

•This general model is widely applicable

ProgramProgramInput Output

Page 45: Week 3 Part I

Relation to Functions

•Consider the function printf

printfprintf

Formatting string,variables to print

Something on theterminal

Page 46: Week 3 Part I

printf Function

printf( “%i\n”, myInteger )

printfprintf

“%i\n”

myInteger

<<myInteger on the terminal>>

Page 47: Week 3 Part I

Functions

•A way of breaking down programs into (more or less) independent units

•Can be tested individually

•Easier to think about

Page 48: Week 3 Part I

Function Input / Output

•Input: parameters (more on this later)

•Output: return value

Page 49: Week 3 Part I

Functions

Input

OutputFunction CFunction C

Function AFunction A

Function BFunction B Output / Input

Page 50: Week 3 Part I

FunctionsInput

OutputFunction CFunction C

Function AFunction A

Function BFunction B Output / Input

functionC( functionA( Input ), functionB( Input ) )

Page 51: Week 3 Part I

Using Functions in C

•Function names have the same rules as variables

•Functions are called like so:

noArguments();printf( “hi” );printf( “%i”, myInteger );

Page 52: Week 3 Part I

Making Functions in C

•Function definition template (p = parameter):

returnType functionName(p1,p2,...,pN) { // function body}

Page 53: Week 3 Part I

Returning

•Functions can optionally return values using the return reserved word

•This is a special output mechanism

Page 54: Week 3 Part I

Examplesint toSecondPower( int number ) { return number * number;}

double doubleIt1( double number ) { return number + number;}

double doubleIt2( double number ) { return number * 2;}

Page 55: Week 3 Part I

Bigger Example

int craziness( double number ) { int x = (int)(number * 2); double y = x + 2; int z = (int)(y * y) + x; return z;}

Page 56: Week 3 Part I

Question

•Return type doesn’t match what’s returned

•What happens?

int mismatch( double number ) { return number;}

Page 57: Week 3 Part I

Answer•Treated as a cast to the return type

int mismatch( double number ) { return number;}

int main() { // prints out 5 printf( “%i\n”, mismatch( 5.5 ) ); return 0;}

Page 58: Week 3 Part I

Question

•Two returns - What happens?

int craziness2( double number ) { int x = (int)(number * 2); return x; double y = x + 2; int z = (int)(y * y) + x; return z;}

Page 59: Week 3 Part I

Answer•Functions can return at most once

•Everything past the first one is ignored

int craziness2( double number ) { int x = (int)(number * 2); return x; double y = x + 2; int z = (int)(y * y) + x; return z;}

Page 60: Week 3 Part I

Question•There is no explicit return

•What happens?

int craziness3( double number ) { int x = (int)(number * 2); double y = x + 2; int z = (int)(y * y) + x;}

Page 61: Week 3 Part I

Answer

•It will return something...but who knows what

•Undefined behavior

•gcc will give a warning if given the -Wall flag

gcc -Wall myProgram.c

Page 62: Week 3 Part I

“May Return”

•Functions don’t necessarily need to return values

•Can still be useful

Page 63: Week 3 Part I

void Return Type

•If a function has a return type of void, this mean it does not return anything

int globalVariable = 0;

void incrementGlobal() { globalVariable++;}

Page 64: Week 3 Part I

void and Return

•return can still be used with void functions

•Simply ends the execution of the function

•Important in discussing control flow

void something() { return;}

Page 65: Week 3 Part I

Question

•Returning something with void

•What happens?

void function() { return 5;}

Page 66: Week 3 Part I

Answer

•Nothing is returned

•gcc gives a warning about this

void function() { return 5;}

Page 67: Week 3 Part I

Function Prototypes

•Needed to tell the compiler a function exists

•Without them, functions have to be ordered carefully or the compiler can get confused

Page 68: Week 3 Part I

Without Prototypesvoid something() { return;}

int getFive() { something(); return 5;}

•Compiles fine

Page 69: Week 3 Part I

Without Prototypesint getFive() { something(); return 5;}

void something() { return;}

prototypes.c:6: warning: conflicting types for ‘something’prototypes.c:2: warning: previous implicit declaration of ‘something’ was here

Page 70: Week 3 Part I

Function Prototypes

•Look just like the definition, but they lack a body

returnType functionName(p1,p2,...,pN);

Page 71: Week 3 Part I

Prototype Exampleint getFive();void something();

int getFive() { something(); return 5;}

void something() { return;}

•Compiles fine

Page 72: Week 3 Part I

Parameters Revisited

int addTen( int input ) { return input + 10;}

...

addTen( 5 );

Page 73: Week 3 Part I

Parameters Revisited

int addTen( int input ) { return input + 10;}

...

addTen( 5 );

Formal Parameter

Actual Parameter

Page 74: Week 3 Part I

Putting it All Together

Page 75: Week 3 Part I

Example

•A program reads in a signed integer

•The program adds 50 to the integer

•The program prints the result out to the user

•functionExample.c