You are here:

C++/C headers


What are the C++ headers and its uses and functions?

Your question is ambiguous. I am not sure if you are asking about header files in general or the C++ standard library headers in particular. I shall answer both, but there is no way in the limited space for AllExpert answers I can give a complete reference on the contents and uses of the C++ standard library headers and I am not sure here if you are asking about the library facilities or just how to use the headers. If I do not cover what you wish to know then please post a follow-up question providing more specific details of what you wish to know.

Header files, as used by C and C++, are text files containing C or C++ source code and are used to share declarations and definitions between compilation units. A compilation unit is the code compiled by the compiler after preprocessing and can be thought of as the code seen by the compiler after all the pre-processing has occurred: files included, macro definitions defined, macro uses expanded, all conditional compilation directives evaluated.

This is needed as each file compiled by the compiler is a totally new context. The compiler has no knowledge of anything it has not seen during compilation of the current source file. A C++ compiler has to know what you are using before you use it. If you call a function Abc that expects to be passed an Xyz then the compiler needs to know about Abc and that it takes an Xyz and what an Xyz is before you make the call to Abc. The way such knowledge is shared between code needing to know about Abc and Xyz is by creating header files that contain the common declarations and definitions.

Typical items placed into header files are function declarations (also known as function prototypes), inline functions and often template function definitions, class definitions, class template definitions and often the template implementation, constants, macros, type aliases (typedef), global data declarations.

Now I am using the terms declaration and definition a lot here, and many people are confused by the difference. Something can be declared to exist many times but it can only be defined once. This is the C++ one definition rule. The scope of “once” depends on the item in question. Entities that are only really seen by the compiler can only be defined once in each compilation unit – this includes class definitions for example.Anything that is visible to the linker (i.e. it has external linkage) can only be defined once for the whole program (or for a whole dynamic linked or shared object library as these are also linked executables, but consist of executable library code rather than executable program code).

In most cases in C++ a definition is also a declaration but not the other way around. Here are some examples:

int Function( int a, int b ); // function declaration

int Function(( int a, int b)  // function definition
    return sqrt(a*a + b*b);

class Class; // class declaration

class Class  // class definition
   Class( int v ) : iV( v ) {}

// ...

   int      iV;

extern int gCount; // global data declaration

int gCount;       // global data definition

For functions and data definitions the definition is what causes storage to be allocated for the function or data, hence the reason for only allowing one of them. For types the definition is what allows the compiler to know the size and details of objects of that type rather than just its name.

In the case of classes I also use the term implementation. This is because a class definition does not necessarily contain definitions of all its members. Often there are some member functions and data that have definitions elsewhere. The rules for such member definitions are the same as for their non-inline member counterparts. The collection of these class member definitions outside of the class definition I call the class implementation so as not to be confused with the class definition. Usually all parts of a class implementation are placed together in a single source file with the class definition being placed into a header file with a related name (e.g. aclass.h and aclass.cpp).

So if we did not have header files what would be the result? Well, each time you wanted to use a function from a library or another module you would have to add the declaration for it into each source file that used it. Similarly for classes, structs, templates etc., except they would need to be defined rather than just declared. In the case of class and function templates, often the whole class template definition and implementation have to be visible to the compiler in each source file that uses them. All these things have to be consistent between modules. Assuming you have the information for these things azdding them manually to each source file that needs them is tedious, error prone and fragile.

Say we place these details in a file somewhere and copy and paste them into code where we need them. What happens when something is changed in one of these files? All other files that have pasted in the changed details have to be updated manually and all code using the changed facilities may need updating and then the affected projects rebuilt. As these details are in files why not allow them to be included automatically during compilation then when things change we only have to rebuild the affect projects leaving us time to do something more interesting instead, like focussing on updating our code to match the changes. Congratulations we have just invented header files and the #include directive!

To include a header file you precede the quoted name with #include:

#include “myheader.h”

You should generally include such files at the top of a source code file, usually after any comment header and before anything else. You can also include header files from other header files in the same way. A good rule is that a header file should only include those header files it requires to allow its contents to compile without users having to include any other specific header files before it.

For example if header b.h requires something from header a.h but nothing from c.h then if b.h did not include a.h any code the included b.h would have to include a.h first:

#include “a.h”
#include “b.h”

If b.h then required something from d.h this code would fail to compile until d.h is also included:

#include “a.h”
#include “d.h”
#include “b.h”

But what if a.h also needs d.h. then we need to order the includes thus:

#include “d.h”
#include “a.h”
#include “b.h”

Getting the order correct is a waste of time. So b.h should include a.h and later d.h. Then the user of b.h need not care what it requires they just include b.h.

On the other hand b.h should not just include files just in case they might be useful. Each included file means more file access and processing and slows down projects builds, quite dramatically on very large projects. So as b.h needs nothing from c.h it should not include it.

Header files including other header files brings up another problem – of headers being included more than once. If both b.h and c.h include a.h then a source file that includes both:

#include “b.h”
#include “c.h”

Will implicitly include a.h twice – once courtesy of b.h and again courtesy of c.h. This usually leads to things being defined more than once. So header files protect against this using header guards:


// body of header file


The first time headerfile.h is included the preprocessor macro HEADERFILE_H is not defined so the #ifndef conditional code compilation directive includes the code that following it up to the matching #endif directive. The first thing this code does is to define the macro HEADERFILE_H, then goes onto with contents of the header file proper. The closing #endif statement is at the end of the header file. Subsequent inclusions find that the HEADERFILE_H macro is defined so skip including the body of the header file.
C++ has a standard library. The interface to its facilities is of contained in a set of standard defined headers. They are called just headers and drop the usual “.h” or similar extension. So rather than “header.h” a C++ standard library header would be named just “header”. Many facilities came from the C standard library. The C++ names for these headers drop the “.h” extension and add a “c” prefix so “stdio.h” becomes “cstdio”. The thinking is that as the contents of these headers are defined by the C++ standard the C++ library headers need not actually exist as files. A clever compiler could just see the request for the included standard header and add the definitions and declarations etc. for you. I have not as yet come across such a compiler, all the implementations of the C++ standard library I have used have the headers as a set of files.

Using the facilities of the C++ standard library involves including the appropriate headers and ensuring the correct libraries are linked against when building your application. So if you wish to use std::cout to write something on the console you have to include the header <iostream>. Note that I have used < and > around the name. This is because the standard C++ headers are considered system headers and not user headers:

#include <iostream>

If you wish to use a std::vector container type then you include <vector>:

#include <vector>

If you wish to use any of most of the C++ standard library algorithms maybe to sort items or find a specific item in a collection then you include <algorithm>

#include <algorithm>

If you wish to know more about the C++ standard library I suggest you obtain a good reference such as “The C++ Standard Library A Tutorial and Reference” by Nicolai M. Josuttis.

If you really wish to know in exact detail which headers contain what then I suggest you obtain a copy of the C++ standard, which is available in book form (“The C++ Standard”, published by Wiley) or is available as a PDF file for 30 USD from the ANSI online store:  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2016 All rights reserved.