2.12 — Header guards

By Alex on April 5th, 2016 | last modified by Alex on March 31st, 2020

The duplicate definition problem

In lesson 2.7 -- Forward declarations and definitions, we noted that a variable or function identifier can only have one definition (the one definition rule). Thus, a program that defines a variable identifier more than once will cause a compile error:

1 2 3 4 5 6 7

int main() {     int x; // this is a definition for variable x     int x; // compile error: duplicate definition       return 0; }

Similarly, programs that define a function more than once will also cause a compile error:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <iostream>   int foo() // this is a definition for function foo {     return 5; }   int foo() // compile error: duplicate definition {     return 5; }   int main() {     std::cout << foo();     return 0; }

While these programs are easy to fix (remove the duplicate definition), with header files, it’s quite easy to end up in a situation where a definition in a header file gets included more than once. This can happen when a header file #includes another header file (which is common).

Consider the following academic example:

square.h:

1 2 3 4 5 6

// We shouldn't be including function definitions in header files // But for the sake of this example, we will int getSquareSides() {     return 4; }

geometry.h:

1	#include "square.h"

main.cpp:

1 2 3 4 5 6 7

#include "square.h" #include "geometry.h"   int main() {     return 0; }

This seemingly innocent looking program won’t compile! Here’s what’s happening. First, main.cpp #includes square.h, which copies the definition for function getSquareSides into main.cpp. Then main.cpp #includes geometry.h, which #includes square.h itself. This copies contents of square.h (including the definition for function getSquareSides) into geometry.h, which then gets copied into main.cpp.

Thus, after resolving all of the #includes, main.cpp ends up looking like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int getSquareSides()  // from square.h {     return 4; }   int getSquareSides() // from geometry.h (via square.h) {     return 4; }   int main() {     return 0; }

Duplicate definitions and a compile error. Each file, individually, is fine. However, because main.cpp ends up #including the content of square.h twice, we’ve run into problems. If geometry.h needs getSquareSides(), and main.cpp needs both geometry.h and square.h, how would you resolve this issue?

Header guards

The good news is that we can avoid the above problem via a mechanism called a header guard (also called an include guard). Header guards are conditional compilation directives that take the following form:

1 2 3 4 5 6

#ifndef SOME_UNIQUE_NAME_HERE #define SOME_UNIQUE_NAME_HERE   // your declarations (and certain types of definitions) here   #endif

When this header is #included, the preprocessor checks whether SOME_UNIQUE_NAME_HERE has been previously defined. If this is the first time we’re including the header, SOME_UNIQUE_NAME_HERE will not have been defined. Consequently, it #defines SOME_UNIQUE_NAME_HERE and includes the contents of the file. If the header is included again into the same file, SOME_UNIQUE_NAME_HERE will already have been defined from the first time the contents of the header were included, and the contents of the header will be ignored (thanks to the #ifndef).

All of your header files should have header guards on them. SOME_UNIQUE_NAME_HERE can be any name you want, but by convention is set to the full filename of the header file, typed in all caps, using underscores for spaces or punctuation. For example, square.h would have the header guard:

square.h:

1 2 3 4 5 6 7 8 9

#ifndef SQUARE_H #define SQUARE_H   int getSquareSides() {     return 4; }   #endif

Even the standard library headers use header guards. If you were to take a look at the iostream header file from Visual Studio, you would see:

1 2 3 4 5 6

#ifndef _IOSTREAM_ #define _IOSTREAM_   // content here   #endif

For advanced readers

In large programs, it’s possible to have two separate header files (included from different directories) that end up having the same filename (e.g. directoryA\config.h and directoryB\config.h). If only the filename is used for the include guard (e.g. CONFIG_H), these two files may end up using the same guard name. If that happens, any file that includes (directly or indirectly) both config.h files will not receive the contents of the include file to be included second. This will probably cause a compilation error.

Because of this possibility for guard name conflicts, many developers recommend using a more complex/unique name in your header guards. Some good suggestions are a naming convention of <PROJECT>_<PATH>_<FILE>_H , <FILE>_<LARGE RANDOM NUMBER>_H, or <FILE>_<CREATION DATE>_H

Updating our previous example with header guards

Let’s return to the square.h example, using the square.h with header guards. For good form, we’ll also add header guards to geometry.h.

square.h

1 2 3 4 5 6 7 8 9

#ifndef SQUARE_H #define SQUARE_H   int getSquareSides() {     return 4; }   #endif

geometry.h:

1 2 3 4 5 6

#ifndef GEOMETRY_H #define GEOMETRY_H   #include "square.h"   #endif

main.cpp:

1 2 3 4 5 6 7

#include "square.h" #include "geometry.h"   int main() {     return 0; }

After the preprocessor resolves all of the includes, this program looks like this:

main.cpp:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

#ifndef SQUARE_H // square.h included from main.cpp, #define SQUARE_H // SQUARE_H gets defined here   // and all this content gets included int getSquareSides() {     return 4; }   #endif // SQUARE_H   #ifndef GEOMETRY_H // geometry.h included from main.cpp #define GEOMETRY_H #ifndef SQUARE_H // square.h included from geometry.h, SQUARE_H is already defined from above #define SQUARE_H // so none of this content gets included   int getSquareSides() {     return 4; }   #endif // SQUARE_H #endif // GEOMETRY_H   int main() {     return 0; }

As you can see from the example, the second inclusion of the contents of square.h (from geometry.h) gets ignored because SQUARE_H was already defined from the first inclusion. Therefore, function getSquareSides only gets included once.

Header guards do not prevent a header from being included once into different code files

Note that the goal of header guards is to prevent a code file from receiving more than one copy of a guarded header. By design, header guards do not prevent a given header file from being included (once) into separate code files. This can also cause unexpected problems. Consider:

square.h:

1 2 3 4 5 6 7 8 9 10 11

#ifndef SQUARE_H #define SQUARE_H   int getSquareSides() {     return 4; }   int getSquarePerimeter(int sideLength); // forward declaration for getSquarePerimeter   #endif

square.cpp:

1 2 3 4 5 6

#include "square.h"  // square.h is included once here   int getSquarePerimeter(int sideLength) {     return sideLength * getSquareSides(); }

main.cpp:

1 2 3 4 5 6 7 8 9 10

#include "square.h" // square.h is also included once here #include <iostream>   int main() {     std::cout << "a square has " << getSquareSides() << " sides\n";     std::cout << "a square of length 5 has perimeter length " << getSquarePerimeter(5) << '\n';       return 0; }

Note that square.h is included from both main.cpp and square.cpp. This means the contents of square.h will be included once into square.cpp and once into main.cpp.

Let’s examine why this happens in more detail. When square.h is included from square.cpp, SQUARE_H is defined until the end of square.cpp. This define prevents square.h from being included into square.cpp a second time (which is the point of header guards). However, once square.cpp is finished, SQUARE_H is no longer considered defined. This means that when the preprocessor runs on main.cpp, SQUARE_H is not initially defined in main.cpp.

The end result is that both square.cpp and main.cpp get a copy of the definition of getSquareSides. This program will compile, but the linker will complain about your program having multiple definitions for identifier getSquareSides!

The best way to work around this issue is simply to put the function definition in one of the .cpp files so that the header just contains a forward declaration:

square.h:

1 2 3 4 5 6 7

#ifndef SQUARE_H #define SQUARE_H   int getSquareSides(); // forward declaration for getSquareSides int getSquarePerimeter(int sideLength); // forward declaration for getSquarePerimeter   #endif

square.cpp:

1 2 3 4 5 6 7 8 9 10 11

#include "square.h"   int getSquareSides() // actual definition for getSquareSides {     return 4; }   int getSquarePerimeter(int sideLength) {     return sideLength * getSquareSides(); }

main.cpp:

1 2 3 4 5 6 7 8 9 10

#include "square.h" // square.h is also included once here #include <iostream>   int main() {     std::cout << "a square has " << getSquareSides() << "sides\n";     std::cout << "a square of length 5 has perimeter length " << getSquarePerimeter(5) << '\n';       return 0; }

Now when the program is compiled, function getSquareSides will have just one definition (via square.cpp), so the linker is happy. File main.cpp is able to call this function (even though it lives in square.cpp) because it includes square.h, which has a forward declaration for the function (the linker will connect the call to getSquareSides from main.cpp to the definition of getSquareSides in square.cpp).

Can’t we just avoid definitions in header files?

We’ve generally told you not to include function definitions in your headers. So you may be wondering why you should include header guards if they protect you from something you shouldn’t do.

There are quite a few cases we’ll show you in the future where it’s necessary to put non-function definitions in a header file. For example, C++ will let you create your own types. These user-defined types are typically defined in header files, so the definition can be propagated out to the code files that need to use them. Without a header guard, your code files can end up with multiple identical copies of these definitions, which will cause a duplicate definition compilation error.

So even though it’s not strictly necessary to have header guards at this point in the tutorial series, we’re establishing good habits now, so you don’t have to unlearn bad habits later.

#pragma once

Many compilers support a simpler, alternate form of header guards using the #pragma directive:

1 2 3

#pragma once   // your code here

#pragma once serves the same purpose as header guards, and has the added benefit of being shorter and less error-prone.

However, #pragma once is not an official part of the C++ language, and not all compilers support it (although most modern compilers do).

For compatibility purposes, we recommend sticking to traditional header guards. They aren’t much more work and they’re guaranteed to be supported on all compliant compilers.

Summary

Header guards are designed to ensure that the contents of a given header file are not copied more than once into any single file, in order to prevent duplicate definitions.

Note that duplicate declarations are fine, since a declaration can be declared multiple times without incident -- but even if your header file is composed of all declarations (no definitions) it’s still a best practice to include header guards.

Note that header guards do not prevent the contents of a header file from being copied (once) into separate project files. This is a good thing, because we often need to reference the contents of a given header from different project files.

Quiz time

Question #1

Add header guards to this header file:

add.h:

1	int add(int x, int y);

Show Solution

1 2 3 4 5 6

#ifndef ADD_H #define ADD_H   int add(int x, int y);   #endif

2.13 -- How to design your first programs

Index

2.11 -- Header files

C++ Tutorial |  Print This Post

270 comments to 2.12 — Header guards

• Piyush Pranjal

  July 12, 2019 at 3:51 am · Reply

  TYPO ERROR

  need to use them them. = Two "them".

  :)

  • Alex

    July 13, 2019 at 8:10 pm · Reply

    I fixed them them. :) Thanks!

• BP

  June 10, 2019 at 7:36 am · Reply

  Hi!
  I thing this is the best place to place this comment.
  I'm having trouble with my header file Header.h:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  #ifndef HEADER_H #define HEADER_H   void localMain();   namespace birb {     int thing{ 456 }; }   namespace myConstants {     constexpr double gravity{ 9.8 }; }   #endif

  Extra.cpp:

  1 2 3 4 5 6 7 8

  #include <iostream> #include <limits> #include "Header.h"   void localMain() {   }

  And Blankslate.cpp:

  1 2 3 4 5 6 7 8 9 10 11 12 13

  #include <iostream> #include <limits> #include <bitset> #include "Header.h"     int main() {     std::cout << birb::thing;       localMain();     return 0; }

  I keep getting the errors:
  1>Extra.obj : error LNK2005: "int birb::thing" (?thing@birb@@3HA) already defined in BlankSlate.obj
  1>C:\Users\Bastiaan\source\repos\BlankSlate\Debug\BlankSlate.exe : fatal error LNK1169: one or more multiply defined symbols found

  And if I comment out the #include "Header.h" in Extra.cpp the errors disappear.
  I just don't understand why, I thought you could include headerfiles in multiple code files?
  Can't you?

  • nascardriver

    June 10, 2019 at 7:49 am · Reply

    You can, but you can't define a variable twice.
    If you include "Header.h" in 2 files, and `thing` is defined in "Header.h", `thing` will be defined once by "Blankslate.cpp" and once by "Extra.cpp".
    You can declare `thing` `extern` and define it in "Extra.cpp".

    1 2 3 4 5 6 7 8 9 10 11

    // Header.h namespace birb {   extern int thing; }   // Extra.cpp namespace birb {   int thing{ 456 }; }

    `constexpr` variables can be defined multiple times, that's why `gravity` doesn't cause you trouble.

    • BP

      June 10, 2019 at 7:55 am · Reply

      Perfect, thanks!

• KRISHNA KANTH YENUMULA

  June 10, 2019 at 3:13 am · Reply

  Thank you for clear explanation.

• alfonso

  May 10, 2019 at 2:22 am · Reply

  "Header guards are designed to ensure that the contents of a given header file are not copied more than once into any single file.

  Note that header guards do not prevent the contents of a header file from being copied (once) into separate project files.

  There are quite a few cases we’ll show you in the future where it’s necessary to put non-function definitions in a header file."

  Then we'll may have the same definition in multiple files which it's fine for compiler but not for the linker. How do we resolve this issue?

  • nascardriver

    May 10, 2019 at 3:31 am · Reply

    Not everything is affected by the one-definition-rule. For example classes and inline entities can be defined multiple times in separate files.

    • Abhijit

      July 10, 2019 at 8:54 am · Reply

      Can you please give an example?
      Thanks

      • nascardriver

        July 10, 2019 at 8:56 am · Reply

        a.hpp

        1	class C{};

        b.cpp

        1	#include "a.hpp"

        c.cpp

        1	#include "a.hpp"

• Vili Sinervä

  April 27, 2019 at 11:40 pm · Reply

  Hi! In this lesson you're using square.cpp as an example with the following contents:

  1 2 3 4 5 6 7 8 9 10 11 12

  // It would be okay to #include square.h here if needed // This program doesn't need to int getSquareSides() // actual definition for getSquareSides {     return 4; } int getSquarePerimeter(int sideLength) {     return sideLength * getSquareSides(); }

  I understand that not including the associated header file isn't a problem here but shouldn't this lesson conform to the best practice established in the previous lesson (2.11)?

  • Alex

    May 1, 2019 at 2:19 pm · Reply

    Yup, I missed updating that example. Thanks for pointing this out. It's fixed now.

• Juan

  March 9, 2019 at 1:22 pm · Reply

  Thanks for the advice regarding the compatibility of "pragma once". Now it makes more sense to know when to use it.

• Asgar

  February 7, 2019 at 9:12 am · Reply

  Hi again. Regarding header guards on non-function definitions in header files (such as, user defined types), I understand the compiler will complain if duplicate definitions are found. But why is the linker more lenient in this case?

• Asgar

  February 6, 2019 at 10:50 pm · Reply

  You had said previously that, after the pre-processor acts on a code file, the final outcome does not contain any pre-processor directives because the compiler won't understand them.

  But, under the title "Updating our previous example with header guards", you showed a program containing the directives after having gone through the pre-processing phase. Kindly explain.

  • nascardriver

    February 7, 2019 at 6:31 am · Reply

    The example shows the code after resolving #includes, not after fully preprocessing.

    • Asgar

      February 7, 2019 at 8:08 am · Reply

      I see. Wouldn't it be more complete if you mentioned in main.cpp the guard (imported from geometry.h) around the second inclusion of the content from square.h?

      1 2 3 4 5 6 7 8 9 10 11 12 13

      #ifndef GEOMETRY_H #define GEOMETRY_H #ifndef SQUARE_H // included from geometry.h, SQUARE_H is already defined from above #define SQUARE_H // so none of this content gets included int getSquareSides() {     return 4; } #endif   #endif

      • nascardriver

        February 7, 2019 at 8:11 am · Reply

        I agree, let's wait until @Alex sees your comment.

      • Alex

        February 7, 2019 at 8:57 pm · Reply

        Agreed. Lesson updated. Thanks for your feedback!

• Tristan Lee

  January 4, 2019 at 3:19 pm · Reply

  When are should we be using the stdafx.h file?
  It is mentioned in some of the lessons.
  I haven't been including it and my programs work fine.

  • nascardriver

    January 5, 2019 at 3:58 am · Reply

    stdafx.h is no longer used. It was used by vc++ (The compiler used by Visual Studio) to speed up compilation. It has been replaced by pch.h.
    If you're not using VS, you don't need it. If you're using VS, disable precompiled headers and remove the include to allow cross-platform compatibility.

• Jyotish Robin

  December 3, 2018 at 9:09 am · Reply

  Hi!

  I have a doubt regarding including iostream header file in main function and another function which is called from main.
  Eg:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  #include <iostream> #include "calculator.h" int main() {     //This program is meant to mimic the functionality of a calculator which     //support basic arithmetic operations.       //we will ask the user to input the desired operation and operands     getUserInput();       //We perform the mathematical operation and return the result     computeResult();       //We will print the output to the screen     printResult();       return 0; }

  This is the main function.
  Now my getUserInput function is :

  1 2 3 4 5

  #include<iostream> int getUserInput() { //content }

  Since both of the files include iostream, will there be a conflict due to multiple definitions at linking stage?

  • nascardriver

    December 3, 2018 at 11:10 am · Reply

    Hi!

    No, it's fine. You can include headers as many times as you want. Alex talks about why this works later in the tutorials.

    • Jyotish Robin

      December 5, 2018 at 6:14 pm · Reply

      Thanks a lot!

• navroze

  October 31, 2018 at 2:12 am · Reply

  You guys are awesome. This is the complete guide to master this language. Thanks for sharing the content.Cheers!!

• Udit

  September 9, 2018 at 10:37 pm · Reply

  This is one of the best c++ tutorials site I have seen.

• Bjorn

  August 19, 2018 at 4:39 pm · Reply

  Hello the quiz question answer is in the text already and it has been explained before

  • Alex

    August 22, 2018 at 12:00 pm · Reply

    Thanks, quiz removed until I can think up a new one.

• timothy

  August 14, 2018 at 8:30 pm · Reply

  I'm having trouble understanding the point of the forward declaration in square.h, could someone help explain that to me? Thanks

  • nascardriver

    August 15, 2018 at 2:34 am · Reply

    Hi Timothy!

    Without the forward declarations, @main.cpp wouldn't know about the functions in @square.cpp

• Alex Buckley

  August 8, 2018 at 4:00 pm · Reply

  Alex, i don't normally comment on stuff online but this tutorial is awesome, of all the cpp tutorials I've searched up this one was by far the easiest to follow and didn't overwhelm me with 9 billion words per page. 10/10 would recommend.

  • Alex

    August 13, 2018 at 7:59 pm · Reply

    I try to keep the word count to less than 1 billion words per page.

    Thanks for visiting!

• DEXTER RAYNE

  July 31, 2018 at 11:37 pm · Reply

  Hi ALEX,

  CAN I SCREEN-RECORD CERTAIN PAGES FOR PERSONNEL USE ?

  THANKS FOR THIS AWESOME WEBSITE....

  • Alex

    August 2, 2018 at 9:22 pm · Reply

    Yes, you can do whatever you want with the content of the site for personal use only. It's redistribution or rebroadcasting that's harmful.

• Sid

  July 8, 2018 at 9:52 am · Reply

  Hi there Alex! I am not able to understand the difference between declarations and definitions..
  In the code:

  1 2	int x; // this is a definition for identifier x     int x; // compile error: duplicate definition

  Shouldn't that be a declaration? Or am I wrong?

  • Alex

    July 9, 2018 at 4:32 pm · Reply

    * If you're actually allocating memory for something, it's a definition and a declaration.
    * If you're just telling the compiler about the existence of something (e.g. a new type, a forward declaration) that you're going to use later, it's a pure declaration.

    When you see int x used to create a local variable, that's acting as both a declaration and a definition. Because it's a definition, it's susceptible to the one definition rule. Thus, if you try to define int x; again in the same scope, you'll get an error.

    • Sid

      July 10, 2018 at 1:58 am · Reply

      But Am I not just telling the compiler about the existence of the integer x? How is it both a declaration and a definition?

      • nascardriver

        July 10, 2018 at 8:02 am · Reply

        1

        int x;

        also reserves space to store @x, you'll learn how to declare variables without defining them later on.

• amigo

  June 8, 2018 at 4:08 am · Reply

  "Main.cpp is able to call this function (even though it lives in square.cpp) because it includes square.h, which has a forward declaration for the function (the linker will connect the call to getSquareSides() from main.cpp to the definition of getSquareSides() in square.cpp)."

  It doesn't work for me. I have gcc compliant c++11. square.cpp must be included also in main.cpp, otherwise the program do not find the definition of functions defined (not just declared) in square.cpp

  • nascardriver

    June 8, 2018 at 6:13 am · Reply

    Hola amigo!

    Don't include source files. Tell your compiler to compile both files at the same time.
    For g++ the syntax is as follows, other compilers are similar

    1	g++ ./main.cpp ./square.cpp

• Elfry

  May 27, 2018 at 1:14 am · Reply

  It's a bit late but HAPPY ANNIVERSARY! Your site is the best, sir!

• hypost

  May 3, 2018 at 4:18 am · Reply

  I think to know how c++ doesn't work really deepen my understanding more than learning how it works

• Ishtmeet Singh

  April 18, 2018 at 6:18 am · Reply

  Hello Alex,
  Don't you think we should now stick to #pragma once, just to make sure the code is readable, short and less error-prone?
  Most of the compilers these days have support for #pragma once.

  Regards,
  Ishtmeet.

  • Alex

    April 21, 2018 at 3:43 pm · Reply

    I generally try to recommend practices that are an official part of the C++ language, not compiler-specific extensions, even if they are widely adopted.

    I wish C++ would formally adopt #pragma once because it is better than explicitly specifying header guards. But until they do, I won't recommend it, because it may leave your program unable to be compiled on particular compilers.

    For what it's worth, the Google C++ style guide also recommends avoiding #pragma once.

• Paulo Fernando

  April 12, 2018 at 6:48 pm · Reply

  Sorry if it's a noob question...
  I'm confused about this code:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

  math.h   #ifndef MATH_H #define MATH_H int getSquareSides() {     return 4; } #endif     geometry.h:   #ifndef GEOMETRY_H #define GEOMETRY_H #include "math.h" #endif     main.cpp:   #include "math.h" #include "geometry.h" int main() {     return 0; }

  The preprocessor will look file by file and copy the contents of #includes inside each one that is doing a #includes right?
  So when geometry.h does a #include "math.h", it copies to it the: int getSquareSides() definition right?
  And when main.cpp does a #include "math.h" and #include "geometry.h", it is ALSO including int getSquareSides() definition right?
  Shouldn't the linker complain about this duplicate definition? Or the geometry.h won't copy the contents of math.h to itself?
  Help me find out what I'm missing here. Thanks.

  • nascardriver

    April 13, 2018 at 5:44 am · Reply

    Hi Paulo!

    There's no duplicate definition, I've shown the include steps in this comment
    http://www.learncpp.com/cpp-tutorial/1-10a-header-guards/comment-page-3/#comment-322851

• Some guy

  April 2, 2018 at 10:58 pm · Reply

  "Now, when main.cpp #includes “math.h”, the preprocessor will see that MATH_H hasn’t been defined yet. The contents of math.h are copied into main.cpp, and MATH_H is defined. main.cpp then #includes “geometry.h”, which just #includes “math.h”. At this point, the preprocessor sees that MATH_H has previously been defined, and the contents between the header guards are skipped."

  How can the preprocessor see that MATH_H has already been defined if there is no header guard for MATH.H in GEOMETRY.H?

  • nascardriver

    April 3, 2018 at 4:02 am · Reply

    Hi!

    Let's look at what happens when the files have been included:

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

    #ifndef MATH_H #define MATH_H int getSquareSides() {     return 4; } #endif   #ifndef GEOMETRY_H #define GEOMETRY_H #include "math.h" #endif int main() {     return 0; }

    Now, walk through the code line by line

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

    #ifndef MATH_H // MATH_H isn't yet defined, #define MATH_H // so we define it and go on. int getSquareSides() {     return 4; } #endif // MATH_H   #ifndef GEOMETRY_H // GEOMETRY_H isn't yet defined, #define GEOMETRY_H // so we define it and go on. #ifndef MATH_H // MATH_H is already defined #define MATH_H // This code won't be compiled int getSquareSides() {     return 4; } #endif // MATH_H #endif // GEOMETRY_H int main() {     return 0; }

    So the final code looks like this

    1 2 3 4 5 6 7 8 9

    int getSquareSides() {     return 4; } int main() {     return 0; }

    • Nguyen

      June 1, 2018 at 6:16 pm · Reply

      Hi nascardriver,

      Please allow me to make up a similar example.  What does the final code look like?  and What is the output?  Thank you.

      #ifndef MATH_H // MATH_H isn't yet defined,
      #define MATH_H // so we define it and go on.

         std::cout << "AAA" << std::endl;

      #endif // MATH_H

      #ifndef GEOMETRY_H // GEOMETRY_H isn't yet defined,
      #define GEOMETRY_H // so we define it and go on.

         std::cout << "BBB" << std::endl;

      #ifndef MATH_H // MATH_H is already defined
      #define MATH_H // This code won't be compiled

         std::cout << "AAA" << std::endl;

      #endif // MATH_H

      #endif // GEOMETRY_H

      int main()
      {
         std::cout << "CCC" << std::endl;
         return 0;
      }

      • nascardriver

        June 2, 2018 at 2:56 am · Reply

        1 2 3 4 5 6 7 8

        std::cout << "AAA" << std::endl; std::cout << "BBB" << std::endl;   int main() {   std::cout << "CCC" << std::endl;   return 0; }

        Doesn't compile so no output.
        You can check this yourself by generating pre-processed files. For g++ the command is

        1	g++ -E ../src/main.cpp -o main.i

        -E  Stop after preprocessing
        -o  Output file

        Output for your code

        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

        # 1 "../src/main.cpp" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "../src/main.cpp"          std::cout << "AAA" << std::endl;                std::cout << "BBB" << std::endl; # 22 "../src/main.cpp" int main() {    std::cout << "CCC" << std::endl;    return 0; }

• Georges Theodosiou

  March 30, 2018 at 3:08 am · Reply

  Dear Teacher, please permit me a suggestion: In program

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  #include <iostream> int foo() {     return 5; } int foo() // compile error: duplicate definition {     return 5; } int main() {     std::cout << foo();     return 0; }

  change second return value to some number different than 5, to be clear that problem is same name of functions. Regards.

  • Alex

    March 31, 2018 at 3:39 pm · Reply

    It's actually better the way it is. If I changed it, people might assume the compiler only complains if the function definition is different. In fact, the actual definition content don't matter -- it's the fact that there's more than one definition (duplicate or not) that's the issue.

• Georges Theodosiou

  March 28, 2018 at 1:18 am · Reply

  Dear Teacher, please let me following question.
  Header guards prevent duplicate header files. Is there way for prevent duplicate function declaration?

  • Alex

    March 30, 2018 at 4:43 pm · Reply

    No. Duplicate function declarations aren't a problem:

    1 2	int foo(int x); int foo(int x); // okay

    However, Duplicate function definitions are a problem. You can generally avoid that by ensuring you define all your functions in .cpp files.

• Ishak

  March 22, 2018 at 9:57 am · Reply

  How come square.cpp doesnt require that you forward declare the function when it compiles or am I forgetting or confusing something?

  // It would be okay to #include square.h here if needed
  // This program doesn't need to.

  int getSquareSides() // actual definition for getSquareSides
  {
      return 4;
  }

  int getSquarePerimeter(int sideLength)
  {
      return sideLength * getSquareSides();
  }

  • Anuj

    March 31, 2018 at 12:49 pm · Reply

    bcoz square.cpp is a different .cpp file and it doesn't include main function which requires forward declaration to compile if functions are defined after main()...

    for example

    1 2 3 4 5 6 7 8 9 10 11 12 13

    int square()   //requires fwd declaration   int main() { //Code square(); }   int square() {//something       // bcoz square() is defined after main so it needs forward declaration at top }

• Georges Theodosiou

  March 15, 2018 at 7:51 am · Reply

  Dear Teacher,
  Please let me ask you whether following source code is valid c++'s iostream header file. Symbols //@ and /// are confusing me. Former is before second "{" and before first "}".

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

  // Standard iostream objects -*- C++ -*-   // Copyright (C) 1997-2015 Free Software Foundation, Inc. // // This file is part of the GNU ISO C++ Library.  This library is free // software; you can redistribute it and/or modify it under the // terms of the GNU General Public License as published by the // Free Software Foundation; either version 3, or (at your option) // any later version.   // This library is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the // GNU General Public License for more details.   // Under Section 7 of GPL version 3, you are granted additional // permissions described in the GCC Runtime Library Exception, version // 3.1, as published by the Free Software Foundation.   // You should have received a copy of the GNU General Public License and // a copy of the GCC Runtime Library Exception along with this program; // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see // <http://www.gnu.org/licenses/>.   /** @file include/iostream *  This is a Standard C++ Library header. */   // // ISO C++ 14882: 27.3  Standard iostream objects //   #ifndef _GLIBCXX_IOSTREAM #define _GLIBCXX_IOSTREAM 1   #pragma GCC system_header   #include <bits/c++config.h> #include <ostream> #include <istream>   namespace std _GLIBCXX_VISIBILITY(default) { _GLIBCXX_BEGIN_NAMESPACE_VERSION     /**    *  @name Standard Stream Objects    *    *  The &lt;iostream&gt; header declares the eight <em>standard stream    *  objects</em>.  For other declarations, see    *  http://gcc.gnu.org/onlinedocs/libstdc++/manual/io.html    *  and the @link iosfwd I/O forward declarations @endlink    *    *  They are required by default to cooperate with the global C    *  library's @c FILE streams, and to be available during program    *  startup and termination. For more information, see the section of the    *  manual linked to above.   */   //@ {   extern istream cin;             /// Linked to standard input   extern ostream cout;        /// Linked to standard output   extern ostream cerr;        /// Linked to standard error (unbuffered)   extern ostream clog;        /// Linked to standard error (buffered)   #ifdef _GLIBCXX_USE_WCHAR_T   extern wistream wcin;        /// Linked to standard input   extern wostream wcout;    /// Linked to standard output   extern wostream wcerr;    /// Linked to standard error (unbuffered)   extern wostream wclog;    /// Linked to standard error (buffered) #endif   //@ }     // For construction of filebuffers for cout, cin, cerr, clog et. al.   static ios_base::Init __ioinit;   _GLIBCXX_END_NAMESPACE_VERSION } // namespace   #endif /* _GLIBCXX_IOSTREAM */

  Regards.

  • nascardriver

    March 15, 2018 at 8:11 am · Reply

    Hi Georges!

    There is no such thing as 'the iostream header', there are many different versions of it.
    What you posted matches the iostream header installed on my system.

    • Georges Theodosiou

      March 16, 2018 at 12:46 am · Reply

      Dear nascardriver, please accept my thanks for you replied, and for your helpful answer. I understand that what I posted is just a version of "iostream" header file. Regards.

  • Alex

    March 16, 2018 at 3:45 pm · Reply

    Anything that starts with // is a single line comment, so //@ is a comment, as is ///. Why they did this, I have no idea.

    • Georges Theodosiou

      March 17, 2018 at 2:22 am · Reply

      Dear Teacher, please accept my many thanks for you replied, and for your helpful answer.
      Please let me say you another thing I do not understand. I understand that outer body {} belongs to function

      1	namespace std _GLIBCXX_VISIBILITY(default)

      but what about inner body {}?
      Regards.

      • Alex

        March 20, 2018 at 2:46 pm · Reply

        I'm not sure why they put those objects inside an inner block.

        • Georges Theodosiou

          March 23, 2018 at 6:15 am · Reply

          Dear Teacher, please accept my thanks for you replied, and for your motivating answer. It is motivation for me, for learn c++ object and block. Regards.

• gSymer

  March 6, 2018 at 7:31 am · Reply

  What's the difference between .h and .cpp files? Can we write code inside .h files too (as in the third example)?

  • nascardriver

    March 6, 2018 at 7:38 am · Reply

    Hi gSymer!

    You can write code inside header files, but that's not what they're meant for.
    Declarations go in header files and definitions in source files.

• Georges Theodosiou

  February 27, 2018 at 12:50 am · Reply

  Dear Teacher, please let me say that word pragma is transliteration of greek word πραγμα. In general it means "thing" or "stuff". For more information see at
  http://www.wordreference.com/gren/%cf%80%cf%81%ce%b1%ce%b3%ce%bc%ce%b1
  Regards.

• Georges Theodosiou

  February 24, 2018 at 1:56 am · Reply

  Dear Teacher, please let me say that in section "Header guards do not prevent a header from being included once into different code files", in second (correct) program (project) in main.cpp file, comment is

  1	// square.h is also included once here

  I think correct is

  1	// square.h is included only once here

  By the way, color is not the usual green but same as #include ... Regards.