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