Skip to main content
Engineering LibreTexts

8.3: Using a Header File for User Defined Specific Task Functions

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Concept: User Defined Specific Task Functions

    Most companies have certain tasks that are unique to their company. Collectively the programming staff may decide to build several functions and organize them into one or more user libraries. Specific task functions are often built using a testing shell program. The sole purpose of the testing shell program is to create the specific task functions and to test them to insure that they are working properly. Think of a clam, its shell surrounds the important part, the pearl. A testing shell program surrounds the specific task function (the important part). Usually the testing shell program will be used to create several functions that will be placed into a user defined library. The process flows as follows:

    1. The testing shell program with the specific task functions is built and thoroughly tested.
    2. A copy of the testing shell source code is saved as the header file that once modified will be placed in the user library. You delete the main part of the program leaving a comments area, any needed include file references and the specific task functions.

    Shows header file creation

    Figure \(\PageIndex{1}\) Creating a header file from a copy of the testing shell.

    Another copy of the testing shell source code is saved as the prototypes file. This is a text file that retains only the prototypes for the functions that were placed into the header file. The functions should be using meaningful identifier names, thus the prototypes should provide adequate information to others on how to call the function with appropriate parameter passing.

    Shows prototypes file creation

    Figure \(\PageIndex{2}\) Creating a prototypes file from a copy of the testing shell.

    Another copy of the testing shell source code is saved as the verify header program. You delete the functions prototypes and definitions then provide an include that points to the header file. This program is compiled and run to make sure the header file is working properly.

    Shows verify header file creation

    Figure \(\PageIndex{3}\) Creating a verify header file from a copy of the testing shell.

    A good way to understand the concept is to review the four files described above that have been created by a programmer. We will be using the C++ programming language, however the code is easy to understand and will serve our needs well at explaining the concepts; even if you are not familiar with C++.

    Demonstration Using C++

    Creating a Folder or Sub-Folder for the Four Files

    Depending on your compiler/IDE, you should decide where to download and store source code files for processing. Prudence dictates that you create these folders as needed prior to downloading source code files. A suggested sub-folder for the Bloodshed Dev-C++ 5 compiler/IDE might be named:

    • Monitor_Header

    If you have not done so, please create the folder(s) and/or sub-folder(s) as appropriate.

    Download the Four Files

    Download and store the following files to your storage device in the appropriate folder. You may need to right click on some of the links and select "Save Target As" in order to download some of the files.

    Download from Connexions: Monitor_Testing_Shell.cpp

    Download from Connexions: udst_monitor.h

    Download from Connexions: udst_monitor_prototypes.txt

    Download from Connexions: Monitor_Verify_Header.cpp

    Study the Files Collectively to Understand the Concepts

    Take a few moments to review the files in conjunction with the concept discussion above. You should compile and run the Monitor_Testing_Shell.cpp program.

    Creating a Folder or Sub-Folder for your User Library

    Depending on your compiler/IDE, you should decide where to create a folder that will hold the header files you create. We suggest that you create the folder in conjunction with the compiler/IDE software. If you were using the Bloodshed Dev-C++ 5 compiler/IDE you most likely installed the compiler/IDE software at: C:\Dev-Cpp\if you installed it on your machine or at: DriveLetter:\Dev-Cpp\ (where the DriveLetter is the drive that represents your flash drive) if you installed it on a flash drive. We suggest that you create a sub-folder at that location named:

    • user_library

    The path of: C:\Dev-Cpp\user_library would be created as the location for your user library if using your machine installation. You can literally place it anywhere and name the library any name, but once you decide on a place and name; you do not want to move or rename the folders.

    Placing the Header File into the User Library

    You need to copy the udst_monitor.h file placing it into the user_library folder just created. As you can guess the udst stands for user defined specific task. The functions within this header file would be used to control the interaction a user has with the monitor. The .h is a convention of the C++ programming language and indicates a header file. Thus the identifier name for the header file is very meaningful and descriptive.

    Verify that the Header File Works Properly

    Review the Monitor_Verify_Header.cpp source code file and note the two include commands are different.

    1. The Standard Library uses a less than and a greater than to bracket the Standard Library name of: iostream
    2. The user library uses quote marks to bracket the location of the header file. This identifies to the complier that we are specifying the exact file we want. We provide a complete file specification (drive, path information, filename and extension).
    3. Because this item is technically a string within C++, we must use two back slashes between the drive, path(s) and filename. This is because the first back slash assumes that the next character is an escape code and if we really don't want an escape code but a back slash, the second back slash says no I wanted a back slash.This string: "C:\\Dev-Cpp\\user_library\\udst_monitor.h" will be interpreted to mean: C:\Dev-Cpp\user_library\udst_monitor.h

    Depending on what drive you are using, what path folder structure you are using and what you called your folder; you may need to correct the include reference within the source code so that it properly references the header file.

    Compile and run the Monitor_Verify_Header.cpp program. Note: It should work exactly as the Monitor_Testing_Shell.cpp program.


    User Defined Specific Task
    Testing Shell
    A program used to create specific task functions.
    Header File
    A file that contains items we want to have included toward the top of our source code.

    This page titled 8.3: Using a Header File for User Defined Specific Task Functions is shared under a CC BY license and was authored, remixed, and/or curated by Kenneth Leroy Busbee (OpenStax CNX) .

    • Was this article helpful?