CS110_10b_Conclude - EECS110: 10b The Big Ideas We Studied...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: EECS110: 10b The Big Ideas We Studied Jack Tumblin jet@cs.northwestern.edu . 1 `The 8 Big Ideas of C' 1. Nesting, Problem Decomposition 2. Operators, Expressions and Statements Operators 3. Functions, Modules and Interfaces(and ) Functions Interfaces 4. Arrays (and all the above ) 5. Strings (and all the above ) 6. Pointers (and all the above ) 7. Malloc/Free (and all the above ) 8. Structures (and all the above ) Several Ways to Do Most Things (ptr,array,struct, ADT...) 2 Pointers can Arrange Structures Pointers can link together structures Linked structures can have any shape: A `chain' or `loop' (linked list) A `tree' or a `graph' A `grid' or `matrix' or `table' Linked structures are easy, fast to change 3 `Big Ideas' for Debugging (that should be obvious by now) Plan your program before you write it What data structures? What algorithms/methods? What functions? Good idea: write interfaces and stubs first. first Always have a working program Start with a `skeleton' program made of stubs, and/or existing, working code Borrow, re-use, recycle when possible existing libraries, open-source software... 4 `Big Ideas' for Debugging (that should be obvious by now) Solve one problem at a time Never write too much between compiles Keep a `trail of breadcrumbs' Never destroy early versions! keep all versions as your program develops One way: unique, sequential directory names proj4_01 proj4_02 proj4_03 . . . Tools that help: `Revision Control' Software (RCS, CVS,SVN, MS `Visual SourceSafe', etc) 5 `Big Ideas' for Debugging (that should be obvious by now) Lost? Won't Compile &Link? !SIMPLIFY! Remove (comment out) your most recent code, even if you're SURE it is not at fault. No? Do a ruthless binary search: trust NOTHING. NOTHING Comment out HALF your code. Repeat until it runs (even if you're left with only stubs). No? Linking problems? Make one big .c file & keep removing... Then restore code one piece/block at a time Compile after each piece added: trust NOTHING. NOTHING (Are you SURE of every expression? ) (Have you single-stepped through good example data?) Do not go on to the next piece of code until the current piece works properly. (One problem at a time) 6 `Little Ideas' for Debugging (less powerful than `Big Ideas') Most IDEs / Softwe writing tools have a Debugger Must enable it, compile it into your project (CodeBlocks: Project BuildOptions CompileFlags "ProduceDebuggingSymbols[-g]) Most have `breakpoints' (stop here), `Watch' set (show current values of user-specified variables), single-step, step-in, step-out. Enable all possible warnings and flags from compiler & linker Use TOGETHER with the `big ideas' of debugging. Do not go on to the next piece of code until the current piece works properly. (Solve just one problem at a time) 7 Big Programs: The Ugly Truth Computer programming languages, tools make tinkering and elaboration too easy! easy RESULT: Simple programs grow endlessly, RESULT become unreliable, ugly, confusing, even impossible to understand and improve. EXAMPLE: MS Word 2.0: ~40 files, ~8 folders, 0.78 MB! MS Office2000: 1,182 files, 104 folders, 193.65 MB, The history of CS is `saw-toothed' we repeatedly throw away the big ugly mess we made and then start all over again in a new, clean, compact form. EXAMPLE: Mainframe Mid-level Minicomputers Microcomputers Desktops Laptops PDAs & e-books smartphones... 8 Modular Design: Core Platitudes No problem is inherently complicated and tangled-- it is just poorly understood. `Complicated and Tangled'== too many details exposed! --Short , Simple, and Separate modules are Best. Simple --Elaborate and Simple and Separate are good/OK. good/OK --Complicated and Tangled ones are VERY VERY BAD, BAD even if the program is short! Hide the Details--keep interfaces simple & general. Details Solve only one problem at a time! Don't confuse yourself 9 Nested, Modular Design Is our best hope for reliable programs. Idea: Even HUGE programs are kept simple One huge mess, Complicated, Tangled, Interdependent, Disorganized, with Scattered details everywhere, Redundant, Impossible to test, fixing part A breaks part B... `A massive jumbled heap of quick, partial fixes' Many separate modules Elaborate, but step-by-step Self-contained, independent, Orderly, nested interfaces, Details hidden, protected, One task one function Separate, tested functions in separate, tested libraries, Fix the function bodies; don't change the interfaces! 10 Modular Design CORE IDEA: Break problem into just a few primary steps. `Refactor': critically examine/refine/test each step: ? Re-usable parts? ?Any surprises, any forgotten steps? ?Any simpler way? Is your refinement confusing? ?Need to back up, re-organize the larger problem? Repeat: apply above to each step you just made. Absolutely Best Way? Still unknown. `Waterfall', `Extreme Programming' CASE, etc. 11 Modular Design typedef struct gameT { int score; }gameT; int main(void) { int run; game *pIt; run = initGame(pIt); if(TRUE==run) { getInput(pIt); computeOutput(pIt); displayOutput(pIt); } endGame(pIt); } // // current score Structure stub Write function `stubs' and data structure `stubs'. FIRST make it run, THEN make it do something. 12 Modules for Big Programs Manage a 500 function program, 10 authors? Answer: One module per author In C, a module is a pair of files; A .h file (the interface) that holds: Function prototypes #include statements #define statements A .c file (the implementation) that holds: Function bodies only, and one #include, ONLY for its own .h file: #include "myFile.h" 13 Modules and Data Structures Good idea: Organize programs to give each data structure its' own private set of functions. Put the structure & its fcns in one module Example: `birdT' structure Example birdT will have functions for different behaviors: birdInit(), BirdFeed(), BirdSing(), BirdHop(), BirdFly(), BirdPreen(), BirdChirp(), BirdSleep(); bird.c Module bird.h, has birdT struct, functions 14 Nested Modules One module can rely on a `sub-module': module1.h may start with #include "module1A.h" #include "module1B.h" ... module1a.h may start with and so on #include "module1A1.h" #include "module1A2.h" ... One structure can have a smaller `sub-structure' as a member type 15 Big Caution though- Though NESTING of modules is allowed, be careful that your modules don't have any `circular' dependencies... CAUTION! `circular' includes will not work! /* * my1.h file */ #include "my2.h" ... /* * my2.h */ file #include "my1.h" ... 16 A Good Check Draw a graph of . dependencies to be sure: No upward pointing arrows! Objects.h #include #include #include "bird.h" "tree.h" "car.h" Tree.h #include "oak.h" #include "birch.h" #include "maple.h" car.h #include "chevy.h" #include "ford.h" 17 Myprog.c #include "objects.h" int main() { ... } Bird.h #include "owls.h" #include "sparrow.h" #include "hawk.h" 18 ...
View Full Document

This note was uploaded on 10/05/2011 for the course COMPUTER S 110-1 taught by Professor Tumblin during the Spring '11 term at Northwestern.

Ask a homework question - tutors are online