Placing Source Code in Multiple Files

This material is covered in chapter 12 section 3
- But it is hidden in object oriented terms.
- This is a standard practice, not necessairly related to OOP
- So we will cover it now.
Up until now, all of your source code has been placed in a single file.
Well that is not quite true,
- You have used code from header files.
Placing all of your code in a single file is problematic
- It makes it hard to reuse code.
- It makes it hard for multiple people to work on a project.
- It leads to really big files.
The more standard way to develop code is by placing it into seperate files.
- A header
- An implementation file.
Header Files
- These contain declarations like
  - Constant declarations.
  - Function Prototypes
  - Structure declarations.
  - Class declarations.
- These do not contain executable code.
Implementation files
- These contain implementation details.
- Actual code.
Just to simplify things a bit, I am going to create header and implementation files for a string based sort and search.
- We will get more complex later. but let's make it simple for now.
Practical header files.
- The file name should end with a .h
  - I am going to call my file StringUtils.h
- C/C++ has a restriction against declaring anything twice.
  - In this system, there is a danger of doing this.
  - So header files need to inclue a guard
- Guards are statements in the preprocessor language
  - you have seen this before with #incldue
  - There are three statements we will use
  - #ifndef
  - #endif
  - #define
- #ifndef - #endif
  - This is an if statement.
  - But it is a bit strange.
  - It checks to see if something is not defined.
- #define
  - This creates a definition in the language.
- So all header files include the following
  - ```
  #ifndef SOME_CONSTANT
  #define SOME_CONSTANT
  
  // declarations
  
  #endif 
```
- The constant is
  - usually all upper case
  - usually does not start with _ (this is reseved for system files)
    - Take a look at /usr/include/limits.h
  - Related to the program.
- ```
#ifndef DANS_STRING_UTILS
#define DANS_STRING_UTILS

#endif 
```
- What would the function prototypes for these look like?
  - We will have find return size+1 if the key is not in the array.
  - ```
  void Sort(string array[], size_t size);
  size_t Find(string array[], size_t size, string key); 
```
- There is one problem yet.
  - We should include string. Do it.
    - Do it.
  - Strings are part of the standard namespace,
    - It is tempting to includ using namespace std
    - But that is a bad practice.
    - It creates namespace pollution
    - So instead put std:: before the word string.
- The final header file.
- ```
#ifndef DANS_STRING_UTILS
#define DANS_STRING_UTILS

#include <string>

void Sort(const std::string array[], size_t size);
size_t Find(const std::string array[], size_t size, std::string key);

#endif 
```
The implementation file
- This is much simpler.
- Just put code here.
- But no main.
- You generally include the new header file.
- But include with quotes, not angle brackets
- ```
#incldue "StringUtils.h" 
```
How to compile this
- The code in the implementation file needs to be compiled into an object file.
- To do this compile with a -c flag
  - this compiles the file but does not link the results or build an exectuable.
  - This object file is then linked with the main program when it is compile.
- In practice
  - I will compile without any other flags.
  - ```
  g++ -c StringUtils.cpp
  g++ -o main main.cpp StringUtils.o
             
```
- When to compile
  - You need to be careful here.
  - If you change StringUtils.cpp or StringUtils.h you will need to rebuild StringUtils.o
A look at makefiles.
- Remembering to recompile is difficult.
- Remembering to do it at 3am after 12 hours of programming is impossible.
- On the project for my MS, I just pain forgot to compile a file and it took me two days to get it worked out right.
Makefiles automate building multifile systems.
There are sevreal components
- Variables, like
  - CXXFLAGS that make uses by default to tell it how you want to run the c++ compiler.
  - OBJS, which I use to control what will be built.
  - Dependancies
    - all: ${OBJS} tells make that when I type make all, i really want ot build all the things nmed in OBJS
    - main: StringUtils.o tells make that it must build StringUtils.o before it buils main. In addition, it needs to link StringUtils.o with main when it builds the executable for main. StringUtils.o: StringUtils.h tells make that if StringUtils.h changes, it needs to rebuild StringUtils.o
  - Rules
    - These can include dependanceis.
    - But they also include commands you want to run to make those dependencies.
    - clean is an example of this.
  - Make has a number of built in rules
    - For example, it knows that if a file ends in .C or .cpp it should use the g++ compiler to build it.
    - It also knows that if it needs to build foo.o and a file called foo.cpp exists, it runs g++ -c to build it.
- But what is really happening.
  - The compiler is built from a number of parts.
    - The preprocessor
      - handles lines beginning with #
      - Deals with include files for example.
      - This takes source code and produces source code.
      - We can see this if we run gcc -E main.cpp
    - The compiler proper
      - This takes the output of the preprocessor and produces object files.
      - These files represent the code that has been translated into machine language.
      - It does not include the system libraries or other files that need to be linked with this code.
    - The linker
      - This takes the otput of the compler and produces an executable by linking all of the files together.
  - Until now, this has been a single pass operation.
  - Now we need to use the preprocessor and compiler on each source code file.
  - The use the linker to combine them all into a single file.