I'm learning C++ and I have encountered (and fix) what seems to be a very classic problem :
g++ main.cpp A.cpp B.cpp -o out
In file included from B.h:1,
from main.cpp:3:
A.h:1:7: error: redefinition of ‘class A’
1 | class A {
| ^
In file included from main.cpp:2:
Which from a quick research (assuming I understood it correctly), happens because the #include operation is not "idempotent" (a term I discovered with this problem).
To illustrate my question I propose a minimal working example.
main.cpp
#include "A.h"
#include "B.h"
#include <iostream>
int main () {
std::cout << "Hello world" << std::endl;
A a;
B b(a);
return 0;
}
A.h
#include <iostream>
class A {
public:
void test();
};
A.cpp
#include "A.h"
void A::test () {
std::cout << "test" << std::endl;
}
B.h
#include "A.h"
class B {
public:
B(A);
};
B.cpp
#include "B.h"
#include <iostream>
B::B(A a){
a.test();
}
Compiling the program with g++ main.cpp A.cpp B.cpp or more specifically g++ -c main.cpp will fail with the error shown above.
I understand that the compiler transcludes the header of "A" twice when compiling main.cpp (once at main.cpp:1 and once again at B.h:1 during its own inclusing at main.cpp:2). Effectively, the compiler 'sees' the definition of class A twice and thinks we are defining A twice.
What I Fail to understand is the include guards:
To fix this, one may use the keyword: pragma once at the top of the file that is included more than once as such:
A.h fixed with #pragma once
#pragma once
#include <iostream>
class A {
public:
void test();
};
Allowing the program to compile nicely.
To me this suggest that I should start every header with #pragma once !!! Which can't be right is it? Is it common practice? If so, Is there a way to do that at compile time instead (as a flag for instance)?
If I don't, I may not use object A as member of class A nor pass it as argument to B (as in the constructor of B in my example) if such A and B could be used individually in another file; unless I add #pragma once reactively every time the problem pops up which seems "dirty" to me. Furthermore, I would not be able to share my sources with anyone in fear they encounter the situation with two of my objects without having to add pragma once in my files themselves.
What Am I missing? Is there a way to avoid the problem altogether?
To me this suggest that I should start every header with #pragma once !!! Wich can't be right is it?
It can be right. Although it may in theory be a slight exaggeration.
Is it common practice?
Yes, it is. It is fairly universal if we include the other option of using a macro header guard into same practice.
If so, Is there a way to do that at compile time instead (as a flag for instance)?
If you mean, is there a way to make the pre-processor treat every included file as if they contained the pragma whether they have any form of header guard or not then no, there is no way to do that in C++.
In theory, you could write your own pre-processor that does this. However, although such pre-processor would be relatively simple, I would still consider that an unnecessarily complicated solution in relation to the benefit.
unless I add #pragma once reactively every time the problem pops up which seems "dirty" to me.
Is there a way to avoid the problem altogether?
There is a simple way to pre-emptively solve this problem, which you already mentioned: Add the pragma or a traditional macro header guard on top of every header file. There is no need to wait for problems to pop up. Just do this, and your worries are gone.
You can use #pragma once or the more "traditional" include guard.
As you guessed, it should be present in each header file.
In this example you provided:
#pragma once
#include <iostream>
class A {
public:
void test();
};
is not guaranteed to work on all environments. (Like other comments have mentioned.) As well as Circular Dependices.
However using two preprocessor directives: #ifndef and #endif (include guards)
prevents the header file from accidentally being included more than once.
The #ifndef A_H tells the preprocessor to look for a constant named A_H that has not been created with the #define directive.
Now if A_H constant has not been defined then these following lines will be included in the program:
class A {
public:
void test();
};
For example using ifndef and #endif:
#ifndef A_H
#define A_H
class A {
public:
void test();
};
#endif
Related
Suppose I have two data structures that reference each other. I want to put them into their separate header files like this:
// datastruct1.h
#ifndef DATA_STRUCT_ONE
#define DATA_STRUCT_ONE
#include <datastruct2.h>
typedef struct DataStructOne_t
{
DataStructTwo* two;
} DataStructOne;
#endif
and
// datastruct2.h
#ifndef DATA_STRUCT_TWO
#define DATA_STRUCT_TWO
#include <datastruct1.h>
typedef struct DataStructTwo_t
{
DataStructOne* one;
} DataStructTwo;
#endif
and I have a main function:
#include <datastruct1.h>
#include <datastruct2.h>
int main()
{
DataStructOne* one;
DataStructTwo* two;
}
However my compiler complains:
$ gcc -I. -c main.c
In file included from ./datastruct1.h:4,
from main.c:1:
./datastruct2.h:8:2: error: unknown type name ‘DataStructOne’
8 | DataStructOne* one;
| ^~~~~~~~~~~~~
Why is that? What can I do to fix this?
Why?
In order to understand why, we need to think like a compiler. Let's do that while analysing main.c line by line. What would a compiler do?
#include <datastruct1.h>: Put "main.c" aside (push to the stack of files being processed) and switch to "datastruct1.h"
#ifndef DATA_STRUCT_ONE: hmm, this is not defined, let's continue.
#define DATA_STRUCT_ONE: OK, defined!
#include <datastruct2.h>: Put "datastruct1.h" aside and switch to "datastruct2.h"
#ifndef DATA_STRUCT_TWO: hmm, this is not defined, let's continue.
#define DATA_STRUCT_TWO: OK, defined!
#include <datastruct1.h>: Put "datastruct2.h" aside and switch to "datastruct1.h"
#ifndef DATA_STRUCT_ONE: this is now defined, so go straigh to #endif.
(end of "datastruct1.h"): close "datastruct1.h" and pop current file from the stack of filles. What were I doing? Ahh, "datastruct2.h". Let's continue from the place where we left.
typedef struct DataStructTwo_t ok, starting a struct definition
DataStructOne* one; Wait, what is DataStructOne? We have not seen it? (looking up the list of processed lines) Nope, no DataStructOne in sight. Panic!
What happened? In order to compile "datastruct2.h", the compiler needs "datastruct1.h", but the #include guards in it "datastruct1.h" prevent its content from being actually included where it's needed.
The situation is symmetrical, so if we switch the order of #include directives in "main.c", we get the same result with the roles of the two files reversed. We cannot remove the guards either, because that would cause an infinite chain of file inclusions.
It appears that we need "datastruct2.h" to appear before "datastruct1.h" and we need "datastruct1.h" to appear before "datastruct2.h". This does not seem possible.
What?
The situation where file A #includes file B which in turn #includes file A is clearly unacceptable. We need to break the vicious cycle.
Fortunately C and C++ have forward declarations. We can use this language feature to rewrite our header files:
#ifndef DATA_STRUCT_ONE
#define DATA_STRUCT_ONE
// No, do not #include <datastruct2.h>
struct DataStructTwo_t; // this is forward declaration
typedef struct DataStructOne_t
{
struct DataStructTwo_t* two;
} DataStructOne;
#endif
In this case we can rewrite "datastruct2.h" the same way, eliminating its dependency on "datastruct1.h", breaking the cycle in two places (strictly speaking, this is not needed, but less dependencies is always good). Alas. this is not always the case. Often there is only one way to introduce a forward declaration and break the cycle. For ecample, if, instead of
DataStructOne* one;
we had
DataStructOne one; // no pointer
then a forward declaration would not work in this place.
What if I cannot use a forward declaration anywhare?
Then you have a design problem. For example, if instead of both DataStructOne* one; and DataStructTwo* two; you had DataStructOne one; and DataStructTwo two;, then this data structure is not realisable in C or C++. You need to change one of the fields to be a pointer (in C++: a smart pointer), or eliminate it altogether.
One way to resolve the circular dependency and still use the typedefs where possible is to split the headers into two parts with a separate guard macro for each part. The first part provides typedefs for incomplete struct types and the second part completes the declarations of the struct types.
For example :-
datastruct1.h
#ifndef DATA_STRUCT_ONE_PRIV
#define DATA_STRUCT_ONE_PRIV
/* First part of datastruct1.h. */
typedef struct DataStructOne_t DataStructOne;
#endif
#ifndef DATA_STRUCT_ONE
#define DATA_STRUCT_ONE
/* Second part of datastruct1.h */
#include <datastruct2.h>
struct DataStructOne_t
{
DataStructTwo *two;
};
#endif
datastruct2.h
#ifndef DATA_STRUCT_TWO_PRIV
#define DATA_STRUCT_TWO_PRIV
/* First part of datastruct2.h. */
typedef struct DataStructTwo_t DataStructTwo;
#endif
#ifndef DATA_STRUCT_TWO
#define DATA_STRUCT_TWO
/* Second part of datastruct2.h */
#include <datastruct1.h>
struct DataStructTwo_t
{
DataStructOne *one;
};
#endif
main.c
/*
* You can reverse the order of these #includes or omit one of them
* if you want.
*/
#include <datastruct1.h>
#include <datastruct2.h>
int main(void)
{
DataStructOne *one;
DataStructTwo *two;
}
As mentioned in the comment in main.c above, only one of the headers needs to be included since the other header will be included indirectly anyway.
Well, if both structures reference each other, it is clear that they must be related. The best thing you can do is to put both in one include file (as they are related) but putting them in different and making the compiler to read from one include the other will make the compiler to read the main file... .from main file start reading include A until it gets to the point to include B, and start reading B to the point of the include A again(we'll start reading A again in a recursive manner that has no end) you will never stop reading each file and worse, you will get an error the second time you see the same struct definition (because it has been already defined before)
To allow the user to include any or both files without a problem, a define is made when include file A is encountered:
File A.h
#ifndef INCLUDE_FILE_A
#define INCLUDE_FILE_A
/* ... the whole stuff of file A with the proper includes of other files.*/
#include "B.h"
#endif /* INCLUDE_FILE_A */
and in
File B.h
#ifndef INCLUDE_FILE_B
#define INCLUDE_FILE_B
/* ... the whole stuff of file B with the proper includes of other files.*/
#include "A.h"
#endif /* INCLUDE_FILE_B */
so the definitions made in file A are only used if INCLUDE_FILE_A has not been included previously, and skip them if file A has been included already (and the same for B.h, of course).
If you make the same on file B (but instead with INCLUDE_FILE_B) then you will be secure that both files will be included in either order (depending on how you did it in the first case) and will never be included again (making th e inclussion secure of returning back to the main file.
I'm a C++ newbie, but I wasn't able to find the answer to this (most likely trivial) question online. I am having some trouble compiling some code where two classes include each other. To begin, should my #include statements go inside or outside of my macros? In practice, this hasn't seemed to matter. However, in this particular case, I am having trouble. Putting the #include statements outside of the macros causes the compiler to recurse and gives me "#include nested too deeply" errors. This seems to makes sense to me since neither class has been fully defined before #include has been invoked. However, strangely, when I try to put them inside, I am unable to declare a type of one of the classes, for it is not recognized. Here is, in essence, what I'm trying to compile:
A.h
#ifndef A_H_
#define A_H_
#include "B.h"
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
B.h
#ifndef B_H_
#define B_H_
#include "A.h"
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
main.cpp
#include "A.h"
int main()
{
A a;
}
If it makes a difference, I am using g++ 4.3.2.
And just to be clear, in general, where should #include statements go? I have always seen them go outside of the macros, but the scenario I described clearly seems to break this principle. Thanks to any helpers in advance! Please allow me to clarify my intent if I have made any silly mistakes!
By "the macros" I assume you mean the #ifndef include guards?
If so, #includes should definitely go inside. This is one of the major reasons why include guards exists, because otherwise you easily end up with an infinite recursion as you noticed.
Anyway, the problem is that at the time you use the A and B classes (inside the other class), they have not yet been declared. Look at what the code looks like after the #includes have been processed:
//#include "A.h" start
#ifndef A_H_
#define A_H_
//#include "B.h" start
#ifndef B_H_
#define B_H_
//#include "A.h" start
#ifndef A_H_ // A_H_ is already defined, so the contents of the file are skipped at this point
#endif /*A_H_*/
//#include "A.h" end
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
//#include "B.h" end
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
//#include "A.h" end
int main()
{
A a;
}
Now read the code. B is the first class the compiler encounters, and it includes an A& member. What is A? The compiler hasn't encountered any definition of A yet, so it issues an error.
The solution is to make a forward declaration of A. At some point before the definition of B, add a line class A;
This gives the compiler the necessary information, that A is a class. We don't know anything else about it yet, but since B only needs to include a reference to it, this is good enough. In the definition of A, we need a member of type B (not a reference), so here the entire definition of B has to be visible. Which it is, luckily.
And just to be clear, in general, where should #include statements go?
Inside the include guards, for the reason you mentioned.
For your other problem: you need to forward-declare at least one of the classes, e.g. like this:
#ifndef B_H_
#define B_H_
// Instead of this:
//#include "A.h"
class A;
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
This only works for declarations though: as soon as you really use an instance of A, you need to have defined it as well.
By the way, what Nathan says is true: you can't put class instances into each other recursively. This only works with pointers (or, in your case, references) to instances.
In such situations, i create a common header to be included in all sources with forward declarations:
#ifndef common_hpp
#define common_hpp
class A;
class B;
#endif
Then the individual class header files typically don't need any #includes to reference other classes, if all that's needed are pointers or references to those classes. Half the time though there are other goodies in those headers, but at least any problem with circular references are solved with common.hpp
Oops! I think I found a solution that involves putting the #include statements inside the class and using a forward declaration. So, the code looks like:
#ifndef A_H_
#define A_H_
class B;
#include "B.h"
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
And similarly for class B. It compiles, but is this the best approach?
Dependency between two classes in a good software design can be drawn as a tree.
For this reason C++ won't let two .h files #include each other.
I doubt that this can be done. You're not talking about calling two functions from inside each other recursively, but rather of putting two objects one inside the other recursively. Think about putting a house with a picture of a house with a picture of a house etc... This will take up an infinite amount of space because you'll have an infinite number of houses and pictures.
What you can do is have each of A and B include either pointers or references to each other.
Some compilers (inc. gcc) also support #pragma once however the 'include guards' idiom in your question is the usual practice.
Heyo, I have a question about this issue I am having in C++. I am new to C++ and learning. I have experience in object oriented programming so I am looking for the correct way and solve this issue and why it should be done that way.
Classes
I have separated each class into an interface header file and implementation cpp file.
The first class "Alpha" is my base class:
// a.h
#pragma once
class Alpha
{
public:
virtual void myFunction();
};
Alpha Implementation:
// a.cpp
#include <iostream>
#include "a.h"
void Alpha::myFunction()
{
std::cout << "Class Alpha myFunction" << std::endl;
}
I then have a sub class "Beta":
// b.h
#pragma once
#include "a.h"
#include "a.cpp"
class Beta : public Alpha
{
public:
virtual void myFunction();
};
Beta Implementation:
// b.cpp
#include <iostream>
#include "b.h"
void Beta::myFunction()
{
std::cout << "Class Beta myFunction" << std::endl;
}
I then have what will be like a manager class called "Gamma".
// g.h
#pragma once
#include <vector>
#include "a.h"
#include "a.cpp"
class Gamma
{
public:
void run();
std::vector<std::shared_ptr<Alpha>> alphaCollection;
};
Gamma implementation:
// g.cpp
#include "g.h"
#include "b.h"
#include "b.cpp"
void Gamma::run()
{
Beta localBeta;
alphaCollection.push_back(std::make_shared<Beta>(localBeta));
// example usage
alphaCollection.at(0)->myFunction();
}
Then finally my main:
#include "g.h";
#include "g.cpp";
int main()
{
Gamma objectG;
objectG.run();
}
Why I am doing this
The purpose for all of this being that I want a vector of the base class Alpha in my manager where I can then insert elements of a varying number of base class objects.
I used Beta as an example of a derived class but in the real implementation would have more derived classes such as Charlie, Delta etc.
The goal being that my Manager class Gamma will be able to operate on the vector elements as Alpha objects and each of the sub classes perform their own behavior.
The Problem
I cannot compile the above example because of how Gamma's implementation file includes "g.h" and "b.h" each of which include "a.h" and "a.cpp" thus double including "a.cpp" since it has no header guard.
error C2084: function 'void Alpha::myFunction(void)' already has a body a.cpp
error C2264: 'Alpha::myFunction' : error in function definition or declaration; function not called g.cpp
I have read varying opinions on how to use includes and overall I just feel like a noob in understanding the proper way to organize code to prevent his.
Am I very disorganized?
Should implementation files use header guards too?
Should I be using forward declarations? If so how?
Am I crazy to want the implementation to include the sub class includes while the header includes the base class include only?
Seriously any guidance is appreciated!
Do not #include the cpp files. It's not required and that's what is causing the issue.
#pragma once is the same as an include guard - but remember it's not portable - it's specific to your current compiler.
You should not have include guards in your cpp files because you shouldn't #include them.
You only need to include header files, not .cpp files.
You do not want to use header guards in .cpp files.
You don't need forward declaration here (although you could use it instead)
Your implementations are not including "sub class includes", they are including the header files that define their interface. Your include of a.h is correct in g.h.
Stop #including .cpp files. The .h is the most you'll ever need, and sometimes just a forward declaration is enough. Here, here, and here are decent descriptions of what purposes they serve.
Say I have these two classes:
// a.h
#include "b.h"
and:
// b.h
include "a.h"
I understand there is a problem over here, but how can I fix it and use a objects and their methods in b class and vice versa?
You can use forward declarations, like this:
class B;
class A
{
B* ThisIsValid;
}
class B
{
A SoIsThis;
}
For more information, see this SO question.
As for the preprocessor #includes, there's likely a better way to organize your code. Without the full story, though, it's hard to say.
To extend on #Borealid 's answer:
To avoid problems with circular includes, using an "include guard"
eg.
#ifndef MYFILE_H /* If this is not defined yet, it must be the first time
we include this file */
#define MYFILE_H // Mark this file as already included
// This only works if the symbol we are defining is unique.
// code goes here
#endif
You can use what is called a "forward declaration".
For a function, this would be something like void myFunction(int);. For a variable, it might look like extern int myVariable;. For a class, class MyClass;. These bodiless statements can be included before the actual code-bearing declarations, and provide the compiler with enough information to produce code making use of the declared types.
To avoid problems with circular includes, using an "include guard" - an #ifdef at the top of each header file which prevents it being included twice.
The "other" class can only have a reference or pointer to the "first" class.
in file a.h:
#include "b.h"
struct a {
b m_b;
};
in file b.h:
struct a;
struct b {
a* m_a;
};
void using_the_a_instance(b& theb);
in file b.cpp:
#include "b.h"
#include "a.h"
void using_the_a_instance(b& theb)
{
theb.m_a = new a();
}
I'm a C++ newbie, but I wasn't able to find the answer to this (most likely trivial) question online. I am having some trouble compiling some code where two classes include each other. To begin, should my #include statements go inside or outside of my macros? In practice, this hasn't seemed to matter. However, in this particular case, I am having trouble. Putting the #include statements outside of the macros causes the compiler to recurse and gives me "#include nested too deeply" errors. This seems to makes sense to me since neither class has been fully defined before #include has been invoked. However, strangely, when I try to put them inside, I am unable to declare a type of one of the classes, for it is not recognized. Here is, in essence, what I'm trying to compile:
A.h
#ifndef A_H_
#define A_H_
#include "B.h"
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
B.h
#ifndef B_H_
#define B_H_
#include "A.h"
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
main.cpp
#include "A.h"
int main()
{
A a;
}
If it makes a difference, I am using g++ 4.3.2.
And just to be clear, in general, where should #include statements go? I have always seen them go outside of the macros, but the scenario I described clearly seems to break this principle. Thanks to any helpers in advance! Please allow me to clarify my intent if I have made any silly mistakes!
By "the macros" I assume you mean the #ifndef include guards?
If so, #includes should definitely go inside. This is one of the major reasons why include guards exists, because otherwise you easily end up with an infinite recursion as you noticed.
Anyway, the problem is that at the time you use the A and B classes (inside the other class), they have not yet been declared. Look at what the code looks like after the #includes have been processed:
//#include "A.h" start
#ifndef A_H_
#define A_H_
//#include "B.h" start
#ifndef B_H_
#define B_H_
//#include "A.h" start
#ifndef A_H_ // A_H_ is already defined, so the contents of the file are skipped at this point
#endif /*A_H_*/
//#include "A.h" end
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
//#include "B.h" end
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
//#include "A.h" end
int main()
{
A a;
}
Now read the code. B is the first class the compiler encounters, and it includes an A& member. What is A? The compiler hasn't encountered any definition of A yet, so it issues an error.
The solution is to make a forward declaration of A. At some point before the definition of B, add a line class A;
This gives the compiler the necessary information, that A is a class. We don't know anything else about it yet, but since B only needs to include a reference to it, this is good enough. In the definition of A, we need a member of type B (not a reference), so here the entire definition of B has to be visible. Which it is, luckily.
And just to be clear, in general, where should #include statements go?
Inside the include guards, for the reason you mentioned.
For your other problem: you need to forward-declare at least one of the classes, e.g. like this:
#ifndef B_H_
#define B_H_
// Instead of this:
//#include "A.h"
class A;
class B
{
private:
A& a;
public:
B(A& a) : a(a) {}
};
#endif /*B_H_*/
This only works for declarations though: as soon as you really use an instance of A, you need to have defined it as well.
By the way, what Nathan says is true: you can't put class instances into each other recursively. This only works with pointers (or, in your case, references) to instances.
In such situations, i create a common header to be included in all sources with forward declarations:
#ifndef common_hpp
#define common_hpp
class A;
class B;
#endif
Then the individual class header files typically don't need any #includes to reference other classes, if all that's needed are pointers or references to those classes. Half the time though there are other goodies in those headers, but at least any problem with circular references are solved with common.hpp
Oops! I think I found a solution that involves putting the #include statements inside the class and using a forward declaration. So, the code looks like:
#ifndef A_H_
#define A_H_
class B;
#include "B.h"
class A
{
private:
B b;
public:
A() : b(*this) {}
};
#endif /*A_H_*/
And similarly for class B. It compiles, but is this the best approach?
Dependency between two classes in a good software design can be drawn as a tree.
For this reason C++ won't let two .h files #include each other.
I doubt that this can be done. You're not talking about calling two functions from inside each other recursively, but rather of putting two objects one inside the other recursively. Think about putting a house with a picture of a house with a picture of a house etc... This will take up an infinite amount of space because you'll have an infinite number of houses and pictures.
What you can do is have each of A and B include either pointers or references to each other.
Some compilers (inc. gcc) also support #pragma once however the 'include guards' idiom in your question is the usual practice.