Building code from Multiple Files

• The information we are about to discuss is in the book starting on page 610
  • She ties this tightly to object oriented programming and classes which is wrong.
  • The mechanism has existed in c since the mid 70's, long before classes
• Placing all of the code for a project in a single file has several disadvantages
  • It is difficult for multiple people to work on the code at the same time.
  • It is difficult to reuse code
  • It is difficult to test code.
  • It leads to huge files that are difficult to comprehend
• Think about the cthulhu game
  • We are well on our way to writing this game yet we have not formally tested any portion.
  • Our file has already become quite large.
• If you look at the code you will see the following structure

  • #include
    
    type definition
    constants related to that type
    function prototypes related to that type
    
    type definition
    constants related to that type
    function prototypes related to that type
    
    type definition
    constants related to that type
    function prototypes related to that type
    
    constants for the main routine
    functions for the main routine
    
    int main() {
    }
    
    function definitions
            

  • This is a typical pattern.
• If I could split the code into different files
  • It would clean up my main file.
  • It would allow me physically group like items.
  • It would allow me to use these items in different programs
    • Specifically I could write a test program to test that segment of the code.
• A bit of background on the C++ compiler
  • Logically compilers are split into different stages.
  • The preprocessor prepares the code for the compiler
    • It resolves all preprocessor directives (#command)
    • #include specifies additional code that the program needs.
      • The preprocessor will create intermediate code that includes this code.
      • This may be far more code than you think.
      • Take a look at some include files.
    • There are other constructs, but you mostly don't need to know them.
  • The compiler proper translates c++ code into machine code.
    • It may produce an intermediate file
    • These are called object files
    • They normally end in a .o
  • The linker
    • Connects all of the code in the specified object files
    • Along with system libraries needed
    • To form an executable.
  • 
• We can use this system to our advantage.
  • We can break our code into three "sets" of files.
  • Header, or specification files, that contain
    • type definitions
    • constants
    • function prototypes
    • BUT NO EXECUTABLE CODE
    • think the stuff at the top of the program.
  • Implementation files
    • These contain the code related to the header files.
  • Other files
    • At least main and one-time use functions.
• There are a few things we need.
  • Guards
    • Since header files declare things
    • And you are only allowed to declare something once in c++
    • We need a way to make sure that things are not declared multiple times by including the header file multiple times.
    • This is done with a guard
    • There are two ways to do this
    • Both are preprocessor directives
    • #ifndef
      • This is essentially if not defined
      • This goes at the top of ALL header files.
      • The syntax is

        #ifndef some_string
        #define some_string
        
        code goes here
        
        #endif
                            

      • Generally the string should apply to the file.
      • And it needs to be unique
      • And it should not start with _
      • This is the standard and works everywhere
    • #pragma once
      • This works with most compilers
      • It is an intermediate fix for a better solution

      • #pragma once
        
        code goes here
                           

    • Note, this system will be replaced in c++20 and beyond but will still be in use for quite a while.
  • Local includes
    • If you need an include file from the local directory
    • #include "filename.h"
  • Compiling instructions
    • To compile an object file
    • g++ -c file.cpp to produce file.o
    • g++ -o main main.cpp file1.o file2.o ... to produce main
  • But remember you need to recompile all parts that rely on any changed code each time.
  • Better yet, use make.
• You will need to add dependencies to your Makefile.
  • If ResulT.h and ResultT.cpp are part of your program.
    • ResultT.o: ResultT.h
    • This tells Make that ResultT.o needs to be reproduced if ResultT.h changes.
    • It already knows that ResultT.o needs to be reproduced if ResultT.cpp changes.
  • If PlayerT.h/cpp includes StatusT.h
    • PlayerT.o: PlayerT.h StatusT.h is needed.
    • This way PlayerT.o will be rebuilt if StatusT.h changes.
  • If main depends (includes) on code from StatusT.h, PlayerT.h, ResulT.h and the corresponding .o files.
    • main: StatusT.o PlayerT.o ResultT.o
    • You don't need to build the .h dependencies as they are already built in to the .o dependencies.
  • You could also build a file including a main called StatusTest.cpp
    • This would be responsible for testing the StatusT
    • In Makefile
    • Add StatusTest to ${OBJS} line
    • Add the dependency
    • StatusTest: StatusT.o
    • Put code in StatusTest.cpp to make sure that your StatusT is correct.