1 / 27

Producing an OO System from Code

Section 5.2:. Producing an OO System from Code. Steps: 1. Build executable 2. Test 3. Debug Usually you: Use multiple source files Split interface/implementation into .h/.c [.cpp] Reuse other libraries, objects. Comparing .h and .cpp Files. Frame.h file:

eshana
Download Presentation

Producing an OO System from Code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Section 5.2: Producing an OO System from Code Steps: 1. Build executable 2. Test 3. Debug Usually you: • Use multiple source files • Split interface/implementation into .h/.c [.cpp] • Reuse other libraries, objects

  2. Comparing .h and .cpp Files Frame.h file: class Frame {private: wxCanvas canvas;public: void Clear (); } Frame.cpp File: #include Frame.h void Frame::Clear() {canvas->Clear(); }

  3. Definition: “Dependent” File A is dependent on B if changing B can invalidate A Questions: • If I change a .h file, what must I recompile?

  4. Examples of Dependencies

  5. Example of Class Dependencies #include File.h class FileChooser { public: FileChooser(char* path, char* filter); File AskUser(); ... }; #include FileChooser.h, Directory.h, Selector.h File FileChooser::AskUser() { Directory directory(thePath, theFilter); Selector selector(thePath); … } FileChooser.h --> File.h FileChooser.cc --> FileChooser.h Directory.h Selector.h FileChooser.o --> FileChooser.cc FileChooser.h FileChooser.c

  6. An Association of Objects

  7. Using Dependencies to Control Recompilation for all A in SourceFiles { if (A has changed) { recompile A; for all B in SourceFiles { if B depends on A then recompile B } } } link object files;

  8. Conditional Compilation • Today, want cross-platform code • (platform=OS + Hardware) • #ifdef _WINDOWS_95_ • ... code to include for Windows95 platform • #endif • #ifdef _UNIX_ • ...code to include for Unix platform • #endif

  9. 1) Defined in header file: // This is the file Platform.h #ifndef _PLATFORM_ #define _PLATFORM_ #define _WIN_95_ // use W'95 platform ... #endif 2) Defined via compiler flag: gcc -D_WIN_95_ foo.c //sets _WIN95_=1 Defining Cond. Compilation Variables

  10. Pros/Cons of Incremental Development + Easier testing/debugging + Better risk control + Better team organization + Concrete measurability + Psychological benefits - “Stresses” of new fcts contort original architecture (You may need to take time out to re-architect system)

  11. Incremental Development • Incremental - small steps • Progressive - each step moves towards the final goal • Each step can be (and is) tested and evaluated • Regression testing

  12. Table 5-2 An Incremental Development Plan 1. draw a single rectangle at a fixed location with a fixed color; no moving, resizing or grouping is allowed 2. draw a single rectangle at a user-selected location with a fixed color; no moving, resizing or grouping is allowed 3. draw a single instance of each basic shape at user-selected locations each with a fixed color; no moving, resizing or grouping is allowed 4. draw a single rectangle at a fixed location with a user-selected color; no moving, resizing or grouping is allowed 5. draw a single rectangle at a user-selected location with a user-selected color; no moving, resizing or grouping is allowed 6. (combine steps 3 and 5) draw a single instance of each basic shape at user-selected locations each with a user-selected color; no moving, resizing or grouping is allowed

  13. Tools to Work with Source Code Two categories: • Toolkits • Collection of utilities invoked from command line • Examples: emacs, make, gcc, gdb • Integrated development environments (IDEs) • Example: Visual Studio (Visual C++)

  14. Advantages of ToolKits • Easy to add new tools (just another command) • Easy to upgrade one tool • User can reuse old knowledge • Use your favorite editor, whether you use gcc or javac

  15. Disadvantages of ToolKits • User interfaces of tools may be inconsistent and difficult to use. • Tools usually don’t communicate with each other: • Suppose gdb traps program crash. • Gdb reports source file/line# where program stopped • You must manually find the line# in text editor

  16. Why Developers Like Emacs • Emacs is an extensible text editor • You add new functions by writing mlisp • Loading a file loads a per-language mode • Nice key bindings; one keystroke to recompile, run • Emacs offers many advantages of IDE • Emacs acts as “front end” for all tools • Tools can sync: gdb pops up source in other window • It’s easy to add new tools

  17. Advantages of IDE Approach • IDE user interface is • graphical • offers multiple (synchronized) windows • is usually consistent (across languages) • Information loss among the pieces of the environment is minimized.

  18. Disadvantages of IDE Approach • IDE is closed environment • Hard to add a new tool • Impossible to “fix” an irritating feature • Example: I can choose from several author’s java modes in emacs to find one to my liking, but I’m “stuck” with Visual Studio’s poor indentation algorithm for Java • If you learn to use one IDE, you probably know nothing if you change to another IDE

  19. Section 5.5: Debugging Terms • Failure: Something goes wrong when you run program (Example: computer crashes) • Fault: Segment of code that produced failure (Example: division by zero) • Error: What programmer did wrong that produced fault (Example: “I didn’t expect the user to input zero!”)

  20. Steps in Debugging a System

  21. Common Debugging Situations space time

  22. Using the Assert Macro #include <assert.h> Result Class::Method(int a[], int size, int i) {... assert(i >= 0 && i < size && a[i] > 0); ... }

  23. The System Heap

  24. The Run-Time Stack

  25. Debugging Strategies

  26. Debug Philosophies that Work for Me • Devise test data before you code • Don’t assume that a condition can’t happen • Desk-check your code before you run it and especially before you start using a debugger • If you observe a failure, you have 2 options: • Bad: hack around with debugger until you find bug • Good: reread source/desk check again to find bug • (If you can find one bug, then your code probably has more) • Set up a regression test suite to be sure old bugs don’t resurface

  27. Suggestions About Debugging • Find the fault that caused failure • A fault may remain undiscovered for long time. Look for the possibility of a long-dormant fault • Avoid hopeful corrections; don’t “randomly” change code hoping to fix it • Avoid frustration • Get help! Ron and Didem love you and want you to come to their office hours

More Related