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 #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