Download
1 / 14
140 likes | 169 Views
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, &lily); In the called function: function_name(int * fp, int * ly) *fp = 12; *ly = 15;. Two different ways.
E N D
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, &lily); • In the called function: • function_name(int * fp, int * ly) • *fp = 12; • *ly = 15; Two different ways.
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.
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.
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.
Scop (cont.) • If you use prototypes correctly, and watch what names you use for functions, and formal parameters, you shouldn’t have scope problems.
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);
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
Case Study (cont.) • Also review the “structure chart” in figure 6.11. • Very helpful in keeping track of the design you’re implementing.
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.
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.
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
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 1 2 134513293
\b Backspace \f Form Feed \n New Line \r Return \t Tab \’ Apostrophe \” Double Quote \\ Back Slash \nnn Character number nnn (octal) Additional Special Characters
