Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I cannot post any of my actual code due to the fact I am working with PS3 Dev kits and the source code is not allowed to be released publicly, so I will try my best to explain my problem without using any of the PS3 specific code.
Say I have 2 header file (A.h and B.h) along with 2 matching cpp files (A.cpp and B.cpp)
A.h looks similar to this
#ifndef A_H
#define A_H
#include "B.h"
class A
{
public:
void function1();
void functionA();
B m_b;
};
#endif
While B.h looks like this
#ifndef B_H
#define B_H
#include "A.h"
class B
{
public:
void function2();
void functionB();
A m_a;
};
#endif
Both these classes have other functions the the corresponding cpp files are required to used but I have left out. Within A.cpp I need to use all the functions from A.h and a single function from B.h and within B.cpp I need to use all the functions from B.h and a single function from A.h
So A.cpp currently looks similar to this:
#include A.h
#include B.h
void function1()
{
code;
}
void functionA()
{
code;
m_b.function2();
}
and B.cpp looks like
#include A.h
#include B.h
void function2()
{
code;
}
void functionB()
{
code;
m_a.function1();
}
Now obviously there is a lot more code than this but this is where I am getting the problem when compiling. I get the compiler error "Error 2 error 20: identifier "A" is undefined" and the matching "Error 2 error 20: identifier "B" is undefined". Why?
Preprocessor syntax requires "" or <> around file names in #include directives. Why are you suddenly doing
#include A.h
in your .cpp files when in your .h files you were using a correct syntax
#include "A.h"
???
In any case, including header files into each other in circular fashion will not achieve anything meaningful.
Also, it looks like you are trying to make A a member of B and at the same time make B a member of A. It should be obvious to you that this is an infinitely nested data structure that cannot possibly exist in reality. It is not possible to do anything like that in C++.
A number of problems with this code. (Obviously the #include syntax in your cpp files is wrong, as has been pointed out).
Your A object contains a B, your B contains an A which contains a B which contains an A which contains a B......I think you get the idea.
You need to make at least one of those either a pointer or a reference. Then you need to use forward declaration to let the compiler know that B is a class:
// A.h
class B;
class A {
// ...
B * m_b;
};
// B.h
#include "A.h"
class B {
// ...
A m_a;
};
Note that the circular includes won't work. The include guard ensures that the preprocessor won't go into an infinite loop, but whichever class that appears first would not know what the other class is.
Your cpp code seems to also be defining the class members incorrectly - it should be:
void B::function2(){
//code
}
and so on.
Use class pre-declaration as below:
In file A.h:
class B;
class A
{
...
private:
B m_b;
};
In file B.h:
class B
{
...
private:
A m_a;
};
In all cpp files, always include B.h after A.h.
#inlcude "A.h"
#inlcude "B.h"
Related
I am working on a clock display assignment and my professor wants us to use two classes, NumberDisplay and ClockDisplay. So in total I have two header and three cpp files. When I implemented the first part of the assignment using just the first class everything was fine. I noticed though that my professor wants us to declare a NumberDisplay object inside our ClockDisplay header. I figured just declaring like normal would work like this NumberDisplay hours = NumberDisplay(24); however I am not able to access the information unless I include the NumberDisplay.h file for my ClockDisplay.h. When I do that however I am assuming my errors are due to using #include <NumberDisplay.h> in both my NumberDisplay.cpp and my ClockDisplay.cpp. I just would like to know the proper way to structure my files so that I can properly create NumberDisplay objects in my ClockDisplay header file and then use said objects in my ClockDisplay cpp file.
You can #include "NumberDisplay.h" within ClockDisplay.h. This will allow you to use NumberDisplay objects within your ClockDisplay's class declaration.
As a side note, be sure to use include guards for your headers. This will prevent the header from being included multiple times during compilation. Use #pragma once or
#ifndef NUMBERDISPLAY_H_
#define NUMBERDISPLAY_H_
...
#endif // NUMBERDISPLAY_H_
As user Sean Monroe pointed out about using header or include guards; this may not always be the full answer. This will help in many cases to fix your current problem but if you are not careful you can become a victim of circular includes.
Before I mention anything about that I will briefly describe the differences between #include <someheader.h> and #include "someheader.h". The first one will look where most of your system, os, and compiler and standard libraries files are located through the use of system environment variables that are setup by default through your IDE. The later will look in any immediate directories that are setup in the include paths for the current project with the root path being where the code lives when it is created if working in Visual Studio; other IDE's will more than likely be different, but the concept is still the same.
On circular includes: sometimes having header guards alone is not enough. Take for example:
file a.h
#ifndef A_H
#define A_H
#include "b.h"
class A {
private:
B b;
public:
explicit A( const B& b ) { ... }
};
#endif
file b.h
#ifndef B_H
#define B_H
#include "A.h"
class B {
public:
explicit( A* pA ) { ... }
};
#endif
Here this would generate a circular include and this is something that is very important to be aware of. Regardless of which class A or B you try to create an object of in some other file, namespace, class or function the compiler will try to construct the first class and in order to do so it needs to construct the second class however when trying to construct the second class to complete the first class it goes back and tries to construct the first class again since the next requires the first which is an incomplete object and visa versa. This is not exactly a circular include per say but it is a circular infinite recursion of dependencies of incomplete classes. You can read this Q/A for more information: Resolve Circular Dependencies.
Sometimes it is not enough to just include the appropriate header of one class into the header of another; sometimes you may need to just declare a class prototype and or forward declaration in a class's header then include the header file within that class's cpp file. But this will usually work most often with pointers or references but not local copies since pointers and references are addressed by memory location that have a fixed size in memory. Example:
file A.h
#ifndef A_H
#define A_H
class B;
class A {
private:
B* pB;
public:
explicit A( const B& b );
};
#endif
file A.cpp
#include "A.h"
#include "B.h"
A::A( const B& b ) { ... }
file B.h
#ifndef B_H
#define B_H
#include "A.h"
class B {
public:
B(){ ... }
/*param type*/ someFunc( A* pA ) { /* do something with pA */ }
};
There are more problems than what are discussed here but you can read about them in some of the other answers to the same link that I provided above.
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.
If every header uses #ifndef does this mean compiler errors regarding a circular dependency will not happen?
No, it does not.
It means the compiler won't try to include headers for infinity, but a circular dependency still poses a logical problem, because compilation is performed from top to bottom. Let's take a little look at why:
Source code
a.h
#ifndef A_H
#define A_H
#include "b.h"
struct A
{
B* ptr;
};
#endif
b.h
#ifndef B_H
#define B_H
#include "a.h"
struct B
{
A* ptr;
};
#endif
main.cpp
#include "a.h"
int main()
{
A a;
}
After preprocessor runs
The include guards enable us to actually run the preprocessor and have it finish its work in less-than-infinity time; so fast, actually, that I've done it by hand below. The result is:
struct B
{
A* ptr;
};
struct A
{
B* ptr;
};
int main()
{
A a;
}
The definition of B comes before the definition of A, so that A* ptr; cannot be understood. Sure, you can fix that, but only by reversing the order of inclusion, and then you have the opposite problem. Forward declarations and/or re-architecture are the only ways to resolve it.
Header guards solve a different problem. They do not allow you to simply do whatever you like.
It will not create any circular dependency, it will include the file multiple times as the name 'include' says. This usually happens when the code base is big and the we dont know if this file is already included by another header file.
We can also use a single statement , #pragma once
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.