I have a circular header problem that is different from most of the ones already asked on here. I have two classes that depend on each other but not as members so don't run into the problem of the compiler not being able to calculate the class's sizes. So I'm able to use a forward-declaration to break the cycle.
However, I don't want the client to have to include both these headers to use my classes. The headers should be self-contained so the user doesn't need to be aware of this dependency. Is there some way to do this?
Edit: the tricky part is that A and B must be defined header-only.
In header A.hpp
#ifndef A_HPP
#define A_HPP
#include "B.hpp"
struct A
{
B foo() { ... }
};
#endif
In header B.hpp
#ifndef B_HPP
#define B_HPP
struct A;
struct B
{
void bar()
{
A a = A();
...
}
};
#endif
In main.cpp
#include "B.hpp"
B().bar(); // error: 'a' uses undefined class 'A'
Header B.hpp
#ifndef B_HPP
#define B_HPP
struct A;
struct B
{
void bar();
};
#endif
Source B.cpp
#include "A.hpp"
void B::bar()
{
A a;
}
EDIT. So, if you want header-only implementation, then use AndreyT solution.
If both headers contain code that requires the other type to be complete, then in general case it cannot possibly be implemented by self-contained headers.
In your specific example (which is too simple to be representative), you can simply move the definition if B::bar to A.hpp:
inline void B::bar()
{
A a = A();
...
}
But, of course, having methods of B defined in A.hpp doesn't look very elegant.
If the "inlinedness" of B::bar is important to you, the "industrial" solution would involve placing the definition of B::bar into an additional header file B_aux.hpp. When you include the headers, you should include the "aux" ones after all "normal" ones are included, i.e. in main.cpp you'd have
#include "A.hpp"
#include "B.hpp"
#include "C.hpp"
...
#include "B_aux.hpp"
...
But this is, obviously, not a "self-contained" approach.
Just add a #include "A.hpp" to the bottom of B.hpp. You'll still have a circular include, but now it won't hurt anything.
Usually circular includes are a sign that the two types are closely related, and that could mean that they are a single component. If that is the case, then just merge the two headers into a single header for the component, with the type declarations first and the member function definitions at the end, when both types have been fully defined.
Related
I have an interface ver as
// ver.h
class ver
{
public:
virtual void func()=0;
};
Then ver1 and ver2 implement this interface. ver1 and ver2 differ in the sense they include header test\header.h and test2\header.h. Now test\header.h and test2\header.h are not under my control and are mostly similar except for a function pointer which is the reason for having ver1 and ver2
// test\header.h
#ifndef header
#define header
typedef void
(*FuncPoint)(
struct_type_a
);
#endif
and
// test2\header.h
#ifndef header
#define header
typedef void
(*FuncPoint)(
struct_type_b
);
#endif
Now the implementations
//ver1.h
#include "test\header.h"
class ver1:public ver
{
public:
FuncPoint f;
};
and
//ver2.h
#include "test2\header.h"
class ver2:public ver
{
public:
FuncPoint f;
};
and ver1.cpp and ver2.cpp will be using the respective f
Now the polymorphic behavior comes into play here
//something.cpp
#include "ver.h"
#include "ver1.h"
#include "ver2.h"
ver* somefunc()
{
if (some_condition)
return new ver1();
else
return new ver2();
}
Since something.cpp includes both ver1.h and ver2.h, first test\header1.h gets included and because of the include guards, test\header2.h is not included and hence there is no FuncPoint defined for class ver2 and something.cpp fails to compile.
On the other hand ver1.cpp and ver2.cpp gets compiled successfully since there is only one header.h included.
I could do a #undef header after including ver1.h in something.cpp but that would give redefinition error for other things which are same in test\header.h1 and tes\header2.h.
A simple fix would be to not have FuncPoint f as global variables instead of member variables, this way i won't have to include test\header.h in ver1.h but instead in ver1.cpp.
Is there some other better way to fix this?
EDIT:
I could forward declare struct_type_a and struct_type_b in something.cpp and avoid including ver1.h and ver2.h in something.cpp. But class ver1 and ver2 use other things(to declare members) from test\header.h as well(which are same in both versions).
Don't include header.h in ver1.h or ver2.h but in the respective .cpp files: FuncPoint is a pointer so you can use forward declarations. Since ver1.h and ver2.h will both be included you will need to rename it however where exposed (in the .cpp files you will be able to use the original FuncPoint too, since you include only one definition of it there):
//ver1.h
#include "ver.h"
struct struct_type_a;
typedef void (*FuncPoint_a)(struct_type_a);
class ver1 : public ver
{
public:
FuncPoint_a f;
static ver1 *create();
};
Also the creation of the polymorphic objects must be demanded to methods implemented in the .cpp files, in the create() static method.
Following your code it would become:
//something.cpp
#include "ver.h"
#include "ver1.h"
#include "ver2.h"
ver* somefunc()
{
if (some_condition)
return ver1::create();
else
return ver2::create();
}
In this way the two colliding headers will never be included in the same file.
I've added the inclusion of ver.h in ver1.h (and ver2.h) because this is the source using it. Including it in something.cpp only is not correct (ver1 and ver2 need it) - but not related to the current problem.
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.
I have a number of classes and they are quite close to each other like
class A
{
//code
};
class B
{
A* field;
//code
};
class C: public B
{
//code
};
And so on.
And I want to place them in a separate headers (A.h, B.h...) but to avoid adding every one of this header to projects I need a header like myLib.h, that will be just one needed header to include all the classes that I have wrote. Ho do I achieve it?
Also I think not to use #pragma once; and to make it working
#ifndef _MY_LIB_H
#define _MY_LIB_H
#endif
Where should I place it? In every header?
I've tried doing it like
class A;
class B;
...
in myLib.h
but then adding myLib.h to main.cpp is not enough to use A or B objects there. Also, in B.h that
#inlude myLib.h
void someMethod()
{
//field is instance of A
this.field.otherMethod();
}
causes an error because methods of A are declared in A.h, not in myLib.h.
Sorry for long and tangled question.
You should use a separate include guard in each of A.h, B.h, C.h:
// Note: not a good name for a guard macro (too short)
#ifndef _A_H
#define _A_H
// definition of A
#endif
And then MyLib.h becomes simply:
#include<A.h>
#include<B.h>
#include<C.h>
Of course each of your headers should manually include as many of the others as required so that it can stand alone (e.g. C.h would need to include B.h so that the code compiles if someone includes C.h directly).
In some cases you will not need to have one header include another because a forward declaration is enough -- for example in B.h, where an A* member is declared:
#ifndef _B_H
#define _B_H
class A;
class B
{
A* field;
};
#endif
Besides using the pattern
#ifndef _A_H
#define _A_H
... Stuffs
#endif
in each header, I always add
#ifndef _A_H
#include <A.h>
#endif
#ifndef _B_H
#include <B.h>
#endif
....
to other headers, like myLib.h. This considerably improves the speed of compilation because compiler does not need to load and scan the low level headers if they are already scanned.
I do not add this to my cpp files, because the number of headers in cpp is typically reasonable, while it mich more difficult to track relations between headers.
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.