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: int nNum, string sName, int *pnValue Use upper case for names that are #define d, 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