Presentation is loading. Please wait.

Presentation is loading. Please wait.

Modular Programming From Chapter 6. Output Parameters Pass by reference. In the calling program: int frog, lily; int * frog_ptr=&frog; function_name(frog_ptr,

Similar presentations


Presentation on theme: "Modular Programming From Chapter 6. Output Parameters Pass by reference. In the calling program: int frog, lily; int * frog_ptr=&frog; function_name(frog_ptr,"— Presentation transcript:

1 Modular Programming From Chapter 6

2 Output Parameters Pass by reference. In the calling program: int frog, lily; int * frog_ptr=&frog; function_name(frog_ptr, &lily); In the called function: function_name(int * fp, int * ly) *fp = 12; *ly = 15; Two different ways.

3 Pre and Post Conditions An excellent design technique. Described first in chapter 3 (pg 131) Precondition A condition assumed to be true before a function call. Postcondition A condition assumed to be true after a function call. Normally written in English and verified after the function is written.

4 Introduction to Scope Another word for scope is visibility. #define variables scope begins at their definition and ends at the end of the source file. All functions can “see” these variables. The scope of the name of a function begins with the function prototype and ends with the end of the source file.

5 Scope (cont.) All formal parameter names and local variables are visible only from their declarations to the closing brace of the function in which they are declared. Look at Fig 6.8 and pay particular attention to Table 6.4 until you agree with ALL the visibilities.

6 Scop (cont.) If you use prototypes correctly, and watch what names you use for functions, and formal parameters, you shouldn’t have scope problems.

7 Passing output parameters on Since a formal output parameter is an address already, if you pass it on to a scanf, you don’t need the & operator. Calling program: c = funct(&a, &b); In the called program int funct(int *fa, int *fb) { int lc; scanf(“…”, fa, &lc, fb);

8 Case Study (6.5) If you are a bit shaky with top-down design and implementation, review this case study carefully. Problem Analysis Data Requirements Design Initial algorithm Refinements Implementation Testing

9 Case Study (cont.) Also review the “structure chart” in figure 6.11. Very helpful in keeping track of the design you’re implementing.

10 Debugging Driver A short version of code used to call a specific function. It replaces the code “above” the function in the structure chart. Stub A short version of code used to replace the called functions by a specific function. It replaces the code “below” the function in the structure chart.

11 Top Down and Bottom Up Top down doesn’t need drivers, just use the real code. Bottom up doesn’t need stubs, just use the real code.

12 Intermediate Makefiles # Makefile using variables OBJS = rut1.o fun1.o CC = gcc #DEBUG_FLAGS = -g rut1: $(OBJS) $(CC) $(DEBUG_FLAGS) –o rut1 $(OBJS) rut1.o: rut1.c proto.h $(CC) $(DEBUG_FLAGS) –c rut1.c fun1.o: fun1.c proto.h $(CC) $(DEBUG_FLAGS) –c fun1.c clean: rm rut1 *.o

13 A comment about printf If too many expressions are supplied in the printf statement, the extra ones will be ignored. printf(“%d %d\n”, 1, 2, 3); If there are not enough expressions, C will generate strange numbers for the missing expressions. printf(“%d %d %d \n”, 1, 2 ); 1 2 134513293 1 2

14 Additional Special Characters \b Backspace \f Form Feed \n New Line \r Return \t Tab \’ Apostrophe \” Double Quote \\ Back Slash \nnn Character number nnn (octal)


Download ppt "Modular Programming From Chapter 6. Output Parameters Pass by reference. In the calling program: int frog, lily; int * frog_ptr=&frog; function_name(frog_ptr,"

Similar presentations


Ads by Google