Motivation

• Goal of reusable software
  • "Write once, use many (times)
• Develop useful functions, classes, etc, and have them available

A 'Model' to Think About What We're Going to Talk About

• utility programmer / class designer
• application programmer

Calling a Function — What Information is Required?

• Name
• Number and types of parameters
• Return type

Who is Responsible for Making Sure this information is Valid?

• Used to be the programmer
  • Very prone to error
• Modern languages make it the compiler's responsibility

An Example

• What if you don't know the name?
• What if you don't know the number of parameters?
  • Is the size (which is calculated by the function) returned as a parameter?
  • Is the capacity sent (or — ugh — is it a globally defined constant)?
• What if you don't know the order of the parameters?
  • Is the file specification first or last?
• What if you don't know the type of each parameter?
  • Is a string (i.e., the filename) sent?, or an ifstream (an already opened file)
• What about the return type?
  • Is the size returned as the value of the function or as a reference (writeback) parameter?

Separate Compilation

• Want to code and place useful functions in a separate file which can then be brought in to any program that wants to use one or more of those functions
  • Writing and placing those functions is the job of the utility programmer
  • Using those functions is the job of the application programmer
• The application programmer (or the compiler when compiling the application programmer's code) needs to know the following information about each function:
  • name
  • number, type and order of the parameters
  • return type
• In a single source file program, we use function headers at the top of the file to provide this information to the compiler
• For a multi-source-file program, we dont want to have to write the same function headers over and over in each source file
• We will use a header file instead
  • Will contain the function headers of a collection of (usually related) functions
  • The functions themselves will reside in a separate, but related file (more on that soon)
• An application programmer who wishes to use these functions can then include their headers using a #include statement

Modules

• The .cpp file contains the definitions (i.e., function bodies) of the functions of the module.
  • It therefore is often called the implementation, or source file.
    • implementation meaning the actual specification of the algorithm/code of the functions
  • This file is compiled by the module designer (the utility programmer) and the resulting object file is released for distribution.
• The .h file contains the declarations (i.e., function headers) of the functions of the module.
  • It therefore is often called the header, or interface file.
    • interface meaning the manner in which the modules interacts with the outside. i.e, how the functions are called.
  • This file is also created by the module designer (the utility programmer) and is released together with the object file.
    • The application programmer then includes it in their source to obtain access to the module's functions within their own code.

C#include / Macro Guards

#ifndef MY_MODULE_H
#define MY_MODULE_H

…
…
…

#endif

Module Guidelines

• Function headers go in the header file
• Function bodies go in the source file
• Always use include guards
• Always include the heade in the source
• Only source files are compiled

Code Used in This Lecture