Skip to content

Latest commit

 

History

History
109 lines (67 loc) · 4.01 KB

separate-compilation.md

File metadata and controls

109 lines (67 loc) · 4.01 KB

C++ compilation model: Separate Compilation {#separate-comp}

Skeleton descriptions are typeset in italic text, so please don't remove these descriptions when editing the topic.

Overview

Provides a short natural language abstract of the module’s contents. Specifies the different levels of teaching.

Level Objective

Foundational: Basic use of separate compilation

Main: Command of supporting mechanisms and tools

Advanced: Technicalities and tools

Motivation

Why is this important? Why do we want to learn/teach this topic?

This module outlines the issues involved in using separate compilation on multiple program files.

Any non-trivial program will span more than one source file. This makes separate compilation necessary. Separate compilation also leads to quick build times in projects under development.

Topic introduction

Very brief introduction to the topic.

Foundational: Basic use of separate compilation

Background/Required Knowledge

A student:

  1. needs to be able to split function and classes into their declaration and definition. [C++ object model: declarations] [C++ object model: Definitions]

Student outcomes

A list of things "a student should be able to" after the curriculum. The next word should be an action word and testable in an exam. Max 5 items.

A student should be able to:

  1. split a single file program into main, one or more auxiliaries, and header files (or modules), all in one directory
  2. compile and link a program that is spread over multiple files (again, all in one directory), either on the commandline or with a build system.
  3. describe the functions of the various files involved: source, object, executable.

Points to cover

  • Necessity of having function be declared at the locus of use
    • Solving this by explicit declaration or by using header files.

Caveats

This section mentions subtle points to understand, like anything resulting in implementation-defined, unspecified, or undefined behavior.

  • Explain differences (including in desirability) between having explicit declarations of functions in the main program versus using header files or modules.
  • Compilation on a single commandline versus using multiple commands.
  • What needs to be recompiled if only a function is altered? Altered in use syntax versus altered only in semantics.

Main: Command of supporting mechanisms and tools

Background/Required Knowledge

  • All of the above.

Student outcomes

A student should be able to:

  1. Explain what a translation unit is, and its relation to header files.
  2. Use compile flags, including -I and -L to specify search paths.
  3. Make header files for their own code, including using header guards.
  4. Use include directives for the headers of external libraries.

Caveats

  • Build systems make things both easier and harder.
    • Student does not have to set include/library paths.
    • Build systems prevent unnecessary recompilation.
    • Build systems have a separate learning curve.
    • Build systems will pay off when using libraries, less with self-contained student code.

Points to cover

  • Cover the mechanisms for include and library paths to your own code, as well as discovery mechanisms for external libraries.

Advanced: Technicalities and tools

These are important topics that are not expected to be covered but provide guidance where one can continue to investigate this topic in more depth.

  • Language inter-operability: the extern "C" mechanism.
  • Linker conventions including name mangling.
  • The nm tool for inspection object files and libraries, including de-mangling.
  • Understand the issues involved in deciding between include guards and #pragma once.