Overview

• Programs can grow quite large; having all the source in a single file quickly becomes an impossible situation
• Compilation time for large programs can become burdensome. When a program needs modification (either an enhancement or a bug fix), it would be desireable to be able to only have to recompile that portion that was modified.
• Many classes and functions are useful in programs other than the ones in for which they were originally written. In fact, one can imagine classes and functions that have a general usefulness (our array utilities is such an example). It is desireable to be able to have a mechanism other than textual ct/paste by which these can be used in multiple applications.
• Large program development is usually performed by multiple programmers. Although development execution can't proceed until the entire program is coded, each individual programmer should be able to at least compile their code independently of the others.

More on the Creation of an Executable Program

• The first step is known as compilation — the actual translation of your source code into lower-level (usually machine) code
  • This executable code, however, may be incomplete in that it may be using/calling types, variables and functions from other source files
  • Thus there are gaps in the resulting code that need to be filled in
• The second step of the process is called linking or link editing.
  • This step gathers the files that are required to form a complete program and then joins them together, filling in any gaps produced during compilation (more on this in the next section).
  • This produces (or edits) an fully complete executable file.

Source, Object and Executable Files

• The input to the C++ compiler is a source file; its output is an object file
  • The object file consists of:
    • executable code produced by the compiler
    • definitions — these consist of information about variables, and functions defined in the source file.
    • references — these consist of information about the gaps; in particular they contain the location in the file where a variable is used or a function is called, together with the name of the variable or function.
• The input to the linker is a collection of object files; its output is an executable file.
  • The job of the linker is to scan through the object files, finding all the definitions, and then go through the files again resolving all the references with information obtained from the definitions (i.e., it fills in all the gaps).
  • The linker also concatenates all the (fully resolved) object files into a single executable.
  • If a definition is not found for a reference (for example a function is called that is not defined in any of the other object files), the linker would generate an error to the effect of undefined reference or undefined symbol
  • If more than one definition appears for the same variable or function, the linker emits an error along the lines of Duplicate symbol
  • You'll notice the above discussion of the linker omits any mention of types — more on that later.
• Thus, as long as all references can be matched up to a corresponding definition, the linker can construct a complete gap-free executable.
• Functions and/or variables coming defined in another file are called external functions/variables.
• However, the linker only looks at the names, no type information is used! (This is not 100% true, but it's true enough for our discussion).
  • Thus if the linker has a reference for a variable x that needs to be resolved, and it finds the definition of a variable named x, it will resolve the reference, even if the reference is using the variable as an integer and the definition was for a double. (This may be a bit murky at the moment, but you get the general idea — the types of the reference and definition don't match).
  • Similarly if the reference was for a function with one type of signature (say a single integer parameter) and the definition was actually for a different signature (two strings, say), the linker will still resolve the function call.
• This may seem to be a serious issue (and one that requires repair)... and that's where types come into the picture.

Where Types Fit In

• In C++, the notion of a type is a compile-time only concept, i.e., the compiler uses the type of a variable, and then discard it; the type of a variable does not make it into the executable file.
  • The compiler uses the type of a variable (or the signature of a function) to check the legality of code, as well as to determine how to generate machine code.
  • For example, for the statement:

    x = y / z;
    				

    the compile generates a different sort of division operation depending upon whether the two operands were both declared as integers or whether one of them is a double; furthermore, it would generate an error if these are strings.
  • Once the compiler has made sure the code is legal (i.e., makes sense or is semantically valid), and machine code is generated, the types of the variables are no longer needed (in some respects, you can think of it as the machine operations the compiler has chosen 'contains' information in and of themselves about the types).
• But... as we see the compiler itself needs the type information.
  • Here are some examples of this:
    • You must declare a variable before you use it — this is so the compiler knows the type of the variable when it encounters a use of the variable
      • When the compiler reaches the above division/assignment, it must know the types of x, y, and z.
    • Before you can call a function, the compiler must see its signature
      • Since there is a common convention to put main as the first function, we introduce function headers that are placed before main so that the compiler can see the 'type' of the function and make sure it is being called correctly.
      • Note the difference between the declaration of the function (represented by the function header, which simply states the existence of the function and its signature; and the definition of the function, which usually comes later, and which contains the actual code of the function (in the function body).
• It's this type checking on the part of the compiler that prevents the linker problems of the previous section.
  • Even though we will have functions defined in another object file, we will make sure the compiler has access to a declaration of each of these functions whenever and wherever the function is called in other files.
    • And if the compiler does not have access to such a declaration, it will complain (i.e., issue a compilation error.
  • Thus unlike functions we write in the same source file — where we place the declaration (i.e., function header) at the top of the source file, and the definition later in that source file, for functions defined in a separate source/object file, we merely need to place a declaration (function header) at the top of the source file.
  • ... and that's where #include comes in

The Preprocessor

• The preprocessor is the first of several program stages comprising the C++ compilation process
• The preprocessor operates on preprocessor directives (commands) placed in the C++ source file
  • These directives begin with the # symbol
• The preprocessor is strictly a text manipulation facility; it is NOT a compiler and knows nothing about the syntax/semantics of C or C++.
  • The preprocessor makes a pass over the source file applying the commands described below, transforming the original text.
• Here are some preprocessor commands:
  • #define: introduces a macro — a fragment of code that is assigned a name:

    #define PI 3.1415
    #define NUM_ELEMENTS 100
    				

    • Once defined, the macro may be used/invoked by its name, which is replaced by the corresponding code fragment:

      double diameter = …;
      double circumference = diameter * PI;
      						

    • The macro may have arguments which substitute into the code fragment when it is used

      #define TWICE(x) 2 * x	// dangerous (wrong?)!
      						

      • Always surround any appearance of an argument in the code fragment with ()'s
  • #if/#elif/#else/#endif: introduces a (preprocessor-time) conditional that return true if the condition is true (the condition must be one that can be evaluated by the preprocessor, and is typically a macro, or an expression involving macros)

    #define DEBUG 0
    …
    #if DEBUG
    	cout << "The value of i is << i << endl;
    #endif
    				

  • #ifdef/#ifndef: evaluates to true (false) if the condition (which is a macro) has been defined

    #define MACOS
    #ifdef MACOS
    	…
    #else 
    	…
    #endif
    				

    • The macro can also be defined on the command line of the compiler so no source file change needs to be made
  • #include instructs the preprocessor to retrieve the contents of the specified file and physically paste it into the source file at the point where the #include appears.
• All this takes place in the context of a temporary file-— the original source file is not changed.
• More about the preprocessor here.

Header Files and #include

• Instead of making each programmer who wishes to use an external function write the declaration (function header) for that function, we make it the responsibility of programmer who wrote the function definition to also provide a header for that function.
• That header is then placed into a file together with the header of other related functions (think of the functions in array_utils)
• The contents of the header file is then brought into a source file through the use of #include
• The function header is thus available to the compiler when the (external) function is called.
• The file containing these headers is known as a header file and is usually assigned a .h suffix.
  • The name of the file is usually selected to be relevant to the nature of the functions (e.g., array_utils.h).

Module Structure, Include Guards

• Use Include Guards to protect your code from multiple inclusions of the same header file
• Don't use using namespace ... in header files
• Header file structure (non-class)

  #ifndef FILENAME_H
  #define FILENAME_H
  
  #defines
  
  constants
  
  function headers
  ...
  
  #endif
            

• Always #include the corresponding header file
• Implementation file structure

  standard library #includes
  
  user-defined #includes
  
  using namespace std;
  
  #define's
  
  constants
  
  variables
  
  function headers
  
  functions
            

The Source File Containing the External Function Declaration

• The header (.h) file contains the declaration of the external funtion — there must also be a definition of that function (for the linker to be able to use when resolving references to the function).
• These definitions go into a .cpp file (which will be compiled), whose name typically matches the name of the header file, with a suffix of .cpp (rather than .h).
• This file is called the source of implementation file; and we often speak of this as being a module.
• In order to ensure that the prototypes of the declaration and definition remain the same, we insert a #include of the corresponding header (.h) file in the implementation (.cpp) file.
  • This is not really necessary in order to compie the implementation file — its primary purpose is to make sure the .h file's prototypes are in synch with the protoypes of the actual function definitions

A Closer Look At g++

• g++ actually invokes several programs in its translation of a source file to an executable:
  • The preprocessor
  • The compiler proper
  • The linker
• Normally (ie.e, by default — in the absence of any command line options — g++ attempts to build a complete executable from the files specified on its command line. To do this it:
  • invokes the preprocessor on each individual source file on the command line, producing a temporary file corresponding to the expansion of the included header files (the preprocessor performs other replacement tasks as well, but they're of no concern to us at this time).
  • submits this temporary file to the compiler proper; producing an object (.o) file.
  • once all files on the command line have been so processed, the linker is invoked and passed all the object files. Linking is performed, producing an executable (a.out) file.
  • All temporary and object files are deleted.
• There are various permutations to this process
  • For example, if you have already compiled one or more source files into object files (see below), you can specify the object files on the command line; g++ will set them aside, compile any source files and then submit all object files — new and pre-existing to the linker.
• Additionally, one can specify options to g++ to limit which phases are actually executed:
  • -E causes only the preprocessor to run, sending the file resulting from the header file expansions to be sent to standard output (you will have little reason to use this option &mdashl it's one of the exercises below simply so you can see the effects of the preprocessor).
  • -c stops after the compilation phase, retaining the resulting object file; no link is performed.
    • This is the options used on modules (e.g., source files conisting of collections of functions) — there is no main to speak of and thus performing a line would prodcue an undefined symbol error (every executable must have a main; it is the linker that generates the no main error when it fails to find a definition of main).
• Once again, header (.h files are for use by the compiler only-- they contain no executable code, but rather declarations that allow the compiler to check for (type) errors and generate code.
  • As such, it makes no sense to have specify a .h file on the g++ command line — one does not compile such files into an object file; rather they are included in source files for use during compilation.

Code Used in this Lecture