ENERGY 211 / CME 211

1. ENERGY 211 / CME 211 Lecture 26 November 19, 2008

2. Libraries • Nearly all programs need external functions (e.g. Standard Library) • Functions pre-compiled, .o files stored in libraries • Static libraries (.a) contain .o files that are linked with your code • Shared libraries (.so or .dll) are loaded into memory when needed • only one copy of code resides in memory • executable files are kept smaller • costs: functions calls slower, executable less portable due to library version differences

3. Interpreted Languages • C, C++, FORTRAN are compiled languages:code is executed by hardware • MATLAB, Lisp, Java are interpreted languages: code executed by other software (much slower!) • Many interpreted languages provide compilers now, which generate object code • Java instead uses a virtual machine to run intermediate code generated by its compiler, for portability (run slower, everywhere!)

4. Software Engineering • Definition: the task of designing and implementing software • Separate from designing algorithms • A "just do it!" attitude is fine for small programs, but costly for large ones! • Requires: • consideration of the user's perspective, which is very different from that of the programmer • coordination of many people playing diverse roles to make software successful • considerable patience and diligence • high tolerance for stress!

5. Software Life-cycle • Software is eternal, and constantly evolving: • New features • Bug fixes • New hardware • Reliance on other software • With car maintenance, for example, the design stays the same but the parts are updated • With software maintenance, the design is updated and the "parts" remain the same • This makes software maintenance high-risk!

6. Programming in the Large • Requirements specification: what should the program do? • What data structures should be used? (databases?) • What libraries can be used? Will they be too constraining? • How to divide up the work? Is the design modular enough for division? • What language to use? Can it be used to communicate with other software? • How portable should it be? What operating systems might it be run on?

7. Programming in the Small • "Premature optimization of the root of all evil" (Donald Knuth) • Don't optimize until you know you need to • Compilers are very good at optimizing, so let them do their job! • What you can do to help: • Temporal locality: nearby memory accesses in time should be to nearby locations in memory • Memory usage: try to re-use dynamically allocated memory, to cut down on memory leaks and overhead from allocating and de-allocating

8. Variable and Function Names • For code based on mathematical algorithms, which use short (single-character) names, best to use same names • For complex objects that don't have a mathematical representation, use longer, more descriptive names • Some programmers prefix variable names with an indication of its type: intnNum,string sName,int*pnValue • Use upper case for names that are #defined, or have mathematical upper case names

9. Style and Layout • In languages such as C++, indentation is very helpful to for the reader to understand the structure of the program • Always indent the body of a compound statement (anything between { }'s) • Also indent single statements that belong to an if statement or loop • Typical indentation is 4 spaces • Use parentheses to make order of operations clear • Avoid long lines of code; free-format rules allow going to next line without Matlab's '…'

10. Next Time More on Software Engineering • Programming in the Middle • Interface Design • Development Strategies • Documentation • Cross-Language Development • Modularity