SOLVED
What really helped me was that I could #include headers in the .cpp file with out causing the redefined error.
I'm new to C++ but I have some programming experience in C# and Java so I could be missing something basic that's unique to C++.
The problem is that I don't really know what's wrong, I will paste some code to try to explain the issue.
I have three Classes, GameEvents, Physics and GameObject. I have headers for each of them.
GameEvents has one Physics and a list of GameObjects.
Physics has a list of GameObjects.
What I'm trying to achieve is that I want GameObject to be able to access or own a Physics object.
If I simply #include "Physics.h" in GameObject I get the
"error C2111: 'ClassXXX' : 'class' type redifinition" which I understand.
And this is where I thought #include-guards would help so I added an include guard to my Physics.h since that's the header I want to include twice.
This is how it looks
#ifndef PHYSICS_H
#define PHYSICS_H
#include "GameObject.h"
#include <list>
class Physics
{
private:
double gravity;
list<GameObject*> objects;
list<GameObject*>::iterator i;
public:
Physics(void);
void ApplyPhysics(GameObject*);
void UpdatePhysics(int);
bool RectangleIntersect(SDL_Rect, SDL_Rect);
Vector2X CheckCollisions(Vector2X, GameObject*);
};
#endif // PHYSICS_H
But if I #include "Physics.h" in my GameObject.h now like this:
#include "Texture2D.h"
#include "Vector2X.h"
#include <SDL.h>
#include "Physics.h"
class GameObject
{
private:
SDL_Rect collisionBox;
public:
Texture2D texture;
Vector2X position;
double gravityForce;
int weight;
bool isOnGround;
GameObject(void);
GameObject(Texture2D, Vector2X, int);
void UpdateObject(int);
void Draw(SDL_Surface*);
void SetPosition(Vector2X);
SDL_Rect GetCollisionBox();
};
I get multiple issues that don't understand why they're showing up.
If I don't #include "Physics.h" my code runs just fine.
I'm very grateful for any help.
The preprocessor is a program that takes your program, makes some changes (for example include files (#include), macro expansion (#define), and basically everything that starts with #) and gives the "clean" result to the compiler.
The preprocessor works like this when it sees #include:
When you write:
#include "some_file"
The contents of some_file almost literally get copy pasted into the file including it. Now if you have:
a.h:
class A { int a; };
And:
b.h:
#include "a.h"
class B { int b; };
And:
main.cpp:
#include "a.h"
#include "b.h"
You get:
main.cpp:
class A { int a; }; // From #include "a.h"
class A { int a; }; // From #include "b.h"
class B { int b; }; // From #include "b.h"
Now you can see how A is redefined.
When you write guards, they become like this:
a.h:
#ifndef A_H
#define A_H
class A { int a; };
#endif
b.h:
#ifndef B_H
#define B_H
#include "a.h"
class B { int b; };
#endif
So now let's look at how #includes in main would be expanded (this is exactly, like the previous case: copy-paste)
main.cpp:
// From #include "a.h"
#ifndef A_H
#define A_H
class A { int a; };
#endif
// From #include "b.h"
#ifndef B_H
#define B_H
#ifndef A_H // From
#define A_H // #include "a.h"
class A { int a; }; // inside
#endif // "b.h"
class B { int b; };
#endif
Now let's follow the preprocessor and see what "real" code comes out of this. I will go line by line:
// From #include "a.h"
Comment. Ignore! Continue:
#ifndef A_H
Is A_H defined? No! Then continue:
#define A_H
Ok now A_H is defined. Continue:
class A { int a; };
This is not something for preprocessor, so just leave it be. Continue:
#endif
The previous if finished here. Continue:
// From #include "b.h"
Comment. Ignore! Continue:
#ifndef B_H
Is B_H defined? No! Then continue:
#define B_H
Ok now B_H is defined. Continue:
#ifndef A_H // From
Is A_H defined? YES! Then ignore until corresponding #endif:
#define A_H // #include "a.h"
Ignore
class A { int a; }; // inside
Ignore
#endif // "b.h"
The previous if finished here. Continue:
class B { int b; };
This is not something for preprocessor, so just leave it be. Continue:
#endif
The previous if finished here.
That is, after the preprocessor is done with the file, this is what the compiler sees:
main.cpp
class A { int a; };
class B { int b; };
So as you can see, anything that can get #included in the same file twice, whether directly or indirectly needs to be guarded. Since .h files are always very likely to be included twice, it is good if you guard ALL your .h files.
P.S. Note that you also have circular #includes. Imagine the preprocessor copy-pasting the code of Physics.h into GameObject.h which sees there is an #include "GameObject.h" which means copy GameObject.h into itself. When you copy, you again get #include "Pysics.h" and you are stuck in a loop forever. Compilers prevent that, but that means your #includes are half-done.
Before saying how to fix this, you should know another thing.
If you have:
#include "b.h"
class A
{
B b;
};
Then the compiler needs to know everything about b, most importantly, what variables it has etc so that it would know how many bytes it should put in place of b in A.
However, if you have:
class A
{
B *b;
};
Then the compiler doesn't really need to know anything about B (since pointers, regardless of the type have the same size). The only thing it needs to know about B is that it exists!
So you do something called "forward declaration":
class B; // This line just says B exists
class A
{
B *b;
};
This is very similar to many other things you do in header files such as:
int function(int x); // This is forward declaration
class A
{
public:
void do_something(); // This is forward declaration
}
You have circular references here: Physics.h includes GameObject.h which includes Physics.h. Your class Physics uses GameObject* (pointer) type so you don't need to include GameObject.h in Physics.h but just use forward declaration - instead of
#include "GameObject.h"
put
class GameObject;
Furthermore, put guards in each header file.
The issue is that your GameObject.h does not have guards, so when you #include "GameObject.h" in Physics.h it gets included when GameObject.h includes Physics.h.
Add include guards in all your *.h or *.hh header files (unless you have specific reasons to not do that).
To understand what is happening, try to get the preprocessed form of your source code. With GCC, it is something like g++ -Wall -C -E yourcode.cc > yourcode.i (I have no idea on how Microsoft compilers do that). You can also ask which files are included, with GCC as g++ -Wall -H -c yourcode.cc
Firstly you need include guards on gameobject too, but that's not the real problem here
If something else includes physics.h first, physics.h includes gameobject.h, you get something like this:
class GameObject {
...
};
#include physics.h
class Physics {
...
};
and the #include physics.h gets discarded because of the include guards, and you end up with a declaration of GameObject before the declaration of Physics.
But that's a problem if you want GameObject to have a pointer to a Physics, because for htat physics would have to be declared first.
To resolve the cycle, you can forward-declare a class instead, but only if you are just using it as a pointer or a reference in the declaration following, i.e.:
#ifndef PHYSICS_H
#define PHYSICS_H
// no need for this now #include "GameObject.h"
#include <list>
class GameObject;
class Physics
{
private:
list<GameObject*> objects;
list<GameObject*>::iterator i;
public:
void ApplyPhysics(GameObject*);
Vector2X CheckCollisions(Vector2X, GameObject*);
};
#endif // PHYSICS_H
Use include guards in ALL your header files. Since you are using Visual Studio you could use the #pragma once as the first preprocessor definition in all your headers.
However I suggest to use the classical approach:
#ifndef CLASS_NAME_H_
#define CLASS_NAME_H_
// Header code here
#endif //CLASS_NAME_H_
Second read about forward declaration and apply it.
The goal of a header guard is to avoid including the same file many times.
But the header guard that is currently used in C ++ can be improved. The current guard is:
#ifndef AAA_H
#define AAA_H
class AAA
{ /* ... */ };
#endif
My new guard proposal is:
#ifndef AAA_H
#define AAA_H
class AAA
{ /* ... */ };
#else
class AAA; // Forward declaration
#endif
This resolves the annoying problem that occurs when the AAA class needs the BBB class declaration, while the BBB class needs the AAA class declaration, typically because there are crossed pointers from one class to the other:
// File AAA.h
#ifndef AAA_H
#define AAA_H
#include "BBB.h"
class AAA
{
BBB *bbb;
/* ... */
};
#else
class AAA; // Forward declaration
#endif
//+++++++++++++++++++++++++++++++++++++++
// File BBB.h
#ifndef BBB_H
#define BBB_H
#include "AAA.h"
class BBB
{
AAA *aaa;
/* ... */
};
#else
class BBB; // Forward declaration
#endif
I would love for this to be included in the IDEs that automatically generate code from templates.
" #pragma once " ::: serves the same purpose as header guards, and has the added benefit of being shorter and less error-prone.
Many compilers support a simpler, alternate form of header guards using the #pragma directive:
" #pragma once "
// your code here
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, people recommend sticking to traditional header guards. They aren’t much more work and they’re guaranteed to be supported on all compliant compilers.
Related
Related to Error "Unterminated conditional directive" in cross-referencing headers
I have a Serializable template class:
serializable.h
#pragma once
#ifndef SERIALIZABLE_H
#define SERIALIZABLE_H
#include "Logger.h"
#include <string>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/exception/diagnostic_information.hpp>
#include <boost/exception_ptr.hpp>
template<class T>
class Serializable {
public:
static bool Deserialize(Serializable<T>* object, std::string serializedObject) {
try {
return object->SetValuesFromPropertyTree(GetPropertyTreeFromJsonString(serialized));
} catch (...) {
std::string message = boost::current_exception_diagnostic_information();
Logger::PostLogMessageSimple(LogMessage::ERROR, message);
std::cerr << message << std::endl;
}
}
private:
static boost::property_tree::ptree GetPropertyTreeFromJsonString(const std::string & jsonStr) {
std::istringstream iss(jsonStr);
boost::property_tree::ptree pt;
boost::property_tree::read_json(iss, pt);
return pt;
}
}
#endif // SERIALIZABLE_H
But the problem is that the Logger class uses a LogMessage object which inherits from Serializable (using CRTP).
Logger.h
#pragma once
#ifndef LOGGER_H
#define LOGGER_H
#include "LogMessage.h"
class Logger {
public:
static void PostLogMessageSimple(LogMessage::Severity severity, const std::string & message);
}
#endif // LOGGER_H
LogMessage.h
#pragma once
#ifndef LOGMESSAGE_H
#define LOGMESSAGE_H
#include "serializable.h"
class LogMessage : public Serializable<LogMessage> {
public:
enum Severity {
DEBUG,
INFO,
WARN,
ERROR
};
private:
std::string m_timestamp;
std::string m_message;
friend class Serializable<LogMessage>;
virtual boost::property_tree::ptree GetNewPropertyTree() const;
virtual bool SetValuesFromPropertyTree(const boost::property_tree::ptree & pt);
}
#endif // LOGMESSAGE_H
The problem here is that each of these files include the other which causes build errors. Unfortunately, I can't use the solution from the above-linked question (move #include "Logger.h" to Serializable.cpp) because Serializable is a template class, and therefore needs to be defined in the header file.
I'm at a loss for how to proceed. Any help is appreciated!
Edit:
I also considered using a forward declarations of Logger and LogMessage inside serializable.h, but since I'm calling static methods in Logger and using LogMessage::Severity, that doesn't work.
Sometimes a circular dependency requires some analysis of the components that are involved. Figure out why the circle exists, then figure out why it does not need to exist. The analysis can happen at multiple levels. Here are the two levels I would start with.
(Since the code is obviously simplified from the real code, I'll avoid assuming it shows the extent of the true problem. Speaking of which, thanks for not inundating us with overwhelming detail! The code was sufficient to illustrate the problem in general. Any specific suggestions in my answers are similarly intended to illustrate points, not necessarily to be the final solution.)
On one level, you can look at the intent of the classes. Forget the code and focus on purpose. Does it make sense for class A to be unable to define itself without knowing what class B is? Keep in mind that this is stronger than knowing that class B exists (which would equate to a forward definition, header not required). If it doesn't make sense without looking at the code, then maybe you found something to work on. Admittedly, the use of templates complicates matters since the entire implementation needs to be in the header.
For example, a Serializable really should be able to define itself without knowing what will be done with the serialization (i.e. Logger). However, it is a template, and its implementation needs to be able to log an error. So... tricky.
Still, this is a place where one could look for solutions. One possibility might be to separate the error logging into a base piece that handles only strings (already serialized data), and a translation layer that can translate a LogMessage into a string for the base piece. An error during deserialization strongly suggests the lack of anything to serialize, so logging could go directly to the base piece. The dependency circle would break into the chains:
Serializable -> LoggerBase
Logger -> LoggerBase
Logger -> LogMessage -> Serializable -> LoggerBase
At another level, you can take a detailed look at the code, not worrying too much about purpose. You have header A including header B – why? What parts of A actually use something from B? Which parts of B are actually used? Draw up a diagram if you need to better visualize where this dependence lies. Then bring in some consideration of purpose. Are those parts defined in appropriate locations? Are there other possibilities?
For example, in the sample code, the reason Serializable needs LogMessage is to get access to the enumerate LogMessage::ERROR. This is not a strong reason for needing the entire LogMessage definition. Perhaps a wrapper like PostLogErrorSimple could remove the need to know the severity constant? Maybe the reality is more complicated than that, but the point is that some dependencies can be side-stepped by pushing the dependency into a source file. Sometimes the source file is for a different class.
Another example comes from the Logger class. This class requires LogMessage to get access to the LogMessage::Severity enumeration (i.e. the enumeration that has ERROR as one of its values). This is also not a strong reason for needing an entire class definition. Perhaps the enumeration should be defined elsewhere? As part of Logger perhaps? Or maybe not in a class definition at all? If this approach works, the dependency circle breaks into the chains:
Serializable -> Severity
Serializable -> Logger -> Severity // To get the PostLogMessageSimple function
Logger -> Severity
Ideally, once the enumeration is taken care of, the Logger header would be able get by with just a forward declaration of LogMessage instead of including the full header. (A forward declaration is enough to receive an object by reference. And presumably the full Logger definition would have some functions taking LogMessage parameters.)
If you just have declarations in your class and define the methods out of line you should be able to make it work:
#pragma once
#ifndef SERIALIZABLE_H
#define SERIALIZABLE_H
#include <string>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/exception/diagnostic_information.hpp>
#include <boost/exception_ptr.hpp>
template<class T>
class Serializable {
public:
static bool Deserialize(Serializable<T>* object, std::string serializedObject);
private:
static boost::property_tree::ptree GetPropertyTreeFromJsonString(const std::string & jsonStr);
}
#include "Logger.h"
template < typename T >
inline bool Serializable<T>::Deserialize(Serializable<T>* object, std::string serializedObject) {
try {
return object->SetValuesFromPropertyTree(GetPropertyTreeFromJsonString(serialized));
} catch (...) {
std::string message = boost::current_exception_diagnostic_information();
Logger::PostLogMessageSimple(LogMessage::ERROR, message);
std::cerr << message << std::endl;
}
}
template < typename T >
inline boost::property_tree::ptree Serializable<T>::GetPropertyTreeFromJsonString(const std::string & jsonStr) {
std::istringstream iss(jsonStr);
boost::property_tree::ptree pt;
boost::property_tree::read_json(iss, pt);
return pt;
}
#endif // SERIALIZABLE_H
This has the added bonus of making your class interface clearer.
Consider N headers that each define a class.
Let each of the N headers contain a template or inline function, that therefore needs to be defined in the header, that uses the declaration of all other N-1 classes.
In the example below I use N=4, struct instead of class and an inline member function instead of a template, to actually use the other structs. Of course, each struct definition also use (need) the forward declarations, but I left that out because it isn't relevant for the pattern.
A.h:
#ifndef A_H
#define A_H
// Forward declare everything.
struct A;
struct B;
struct C;
struct D;
struct A {
void use();
};
#endif // A_H
#ifndef B_H
#include "B.h"
#endif
#ifndef C_H
#include "C.h"
#endif
#ifndef D_H
#include "D.h"
#endif
#ifndef A_defs_H
#define A_defs_H
inline void A::use()
{
// Use everything.
B x; C y; D z;
}
#endif // A_defs_H
B.h:
#ifndef B_H
#define B_H
// Forward declare everything.
struct A;
struct B;
struct C;
struct D;
struct B {
void use();
};
#endif // B_H
#ifndef A_H
#include "A.h"
#endif
#ifndef C_H
#include "C.h"
#endif
#ifndef D_H
#include "D.h"
#endif
#ifndef B_defs_H
#define B_defs_H
inline void B::use()
{
// Use everything.
A x; C y; D z;
}
#endif // B_defs_H
C.h:
#ifndef C_H
#define C_H
// Forward declare everything.
struct A;
struct B;
struct C;
struct D;
struct C {
void use();
};
#endif // C_H
#ifndef A_H
#include "A.h"
#endif
#ifndef B_H
#include "B.h"
#endif
#ifndef D_H
#include "D.h"
#endif
#ifndef C_defs_H
#define C_defs_H
inline void C::use()
{
// Use everything.
A x; B y; D z;
}
#endif // C_defs_H
D.h:
#ifndef D_H
#define D_H
// Forward declare everything.
struct A;
struct B;
struct C;
struct D;
struct D {
void use();
};
#endif // D_H
#ifndef A_H
#include "A.h"
#endif
#ifndef B_H
#include "B.h"
#endif
#ifndef C_H
#include "C.h"
#endif
#ifndef D_defs_H
#define D_defs_H
inline void D::use()
{
// Use everything.
A x; B y; C z;
}
#endif // D_defs_H
The guards around each #include are necessary to avoid infinite include depths. Note with just two headers (N = 2) you can also put the includes inside the previous block. For example:
A.h:
#ifndef A_H
#define A_H
// Forward declare everything.
struct A;
struct B;
struct A {
void use();
};
#include "B.h"
#endif // A_H
#ifndef A_defs_H
#define A_defs_H
inline void A::use()
{
// Use everything.
B x;
}
#endif // A_defs_H
and likewise for B.h works fine with N = 2.
I have two classes A and B defined in A.h, A.cpp and B.h, B.cpp respectively. Class A has a structure that I want to use in a function of Class B. Because Class B is included in Class A, I can't include class A in Class B as it will lead to circular dependency. Code for all the files are given below:
A.h
#ifndef _A_H
#define _A_H
#include B.h
namespace common {
class A {
public:
static struct strctOfA {
float p1 = 2;
} structA;
void functionOfA();
};
}
#endif // !_A_H
A.cpp
#include A.h
using namespace common;
A::functionOfA() {
B b;
b.functionOfB(structA);
}
B.h
#ifndef _B_H
#define _B_H
namespace common {
class B {
public:
functionOfB(??);
};
}
#endif // !_B_H
B.cpp
#include B.h
using namespace common;
B::functionOfB(??) {
// Want to use structA here;
}
I looked into StackOverflow and found a thread quite close to my problem, however, they it either doesn't explains the answer or I am not able to understand their solution. Please help me with this.
Thanks
Update
Thanks I-V for pointing out the mistake and providing me the explanation. Updating the code worked for me. Thanks everyone for providing additional knowledge to my C/C++ coding skills. :)
The solution is simple, what you wrote is a bad habit.
There is no reason to include B.h in A.h because you don't use any part of B.h in the A.h file. A better way to implement it is to include B.h in A.cpp and not in the header file.
It will also solve the cycle of includes you have..
In general, it is recommended to include files in .cpp file and NOT in header files when you don't use functions/objects of the included file in the header file :)
In addition, you should use #pragma once for Windows or ifndef for anything else in order to be safe of conflicts
A.h
#ifndef _A_H
#define _A_H
namespace common {
class A {
public:
static struct strctOfA {
float p1 = 2;
} structA;
}
}
#endif
A.cpp
#include A.h
#include B.h
using namespace common;
class A {
B b;
b.functionOfB(structA);
}
NOTE: from B.cpp include A.h
That can be done with forward-declarations, unless you abolutely must pass it by value. But I can't think of a scenario where this wouldn't work with references.
A.h
#ifndef A_H_
#define A_H_
struct B;
struct A {void f(B&);};
#endif
A.cpp
#include "B.h"
void A::f(B & value) {/* do something */ };
B.h
#ifndef B_H_
#define B_H_
struct A;
struct B {void f(B&);};
#endif
B.cpp
#include "A.h"
void B::f(A & value) {/* do something */ };
If you need to have a value of B in A with only a forward-declaration you can put it in a pointer, i.e. use a std::unique_ptr.
Hi I already read similar questions about this topic, but I coudn't resolve my problem.
I think I have to do a forward declaration so I tried the following.
I have three classes A, B and InterfaceA
Defintion InterfaceA
#ifndef INTERFACE_A_H
#define INTERFACE_A_H
#include "B.h"
namespace Example
{
class B; // Forward declaration?
class InterfaceA
{
Example::B test;
};
}
#endif
Definiton class A
#ifndef A_H
#define A_H
#include "InterfaceA.h"
namespace Example
{
class A : public Example::InterfaceA
{
};
}
#endif
Defintion class B
#ifndef B_H
#define B_H
#include "A.h"
namespace Example
{
class A; // Forward declaration?
class B
{
Example::A test;
};
}
#endif
main
#include "A.h"
#include "B.h"
int main()
{
Example::A a;
Example::B b;
}
I get the following error in visual studio:
'Example::B::test' uses undefined class 'Example::A'
Edit:
Thank you so far, for all the help. It was very helpful. I think my problem was that I had a very poor design in my real project. I will change that.
Beside that I have now a better understanding for forward declarations :-)
If you really need that class A references class B and viceversa, instead of having instances of A and B as data members, consider using pointers, e.g. something like this:
// A.h
#pragma once
#include <memory> // for std::unique_ptr
// Forward declaration (A references B using pointer)
class B;
class A
{
...
std::unique_ptr<B> m_pB;
};
And similarly:
// B.h
#pragma once
#include <memory> // for std::unique_ptr
// Forward declaration (B references A using pointer)
class A
class B
{
...
std::unique_ptr<A> m_pA;
};
PS
Not related to the core of your question, however note that I used #pragma once instead of "old style" #ifndef/#define/#endif include guards; #pragma once seems simpler and clearer to me.
You are creating circular dependency. Revise your design.
Do you really need an instance of class A inside B and B inside A?
make them both inherit from the same parent header file, if they need to share header information.
--EDIT --
So sorry that I confused people, I just quickly typed this code out instead of copy and pasting, so I actually do #ifndef A_H #define A_H in my code. Ive changed the below code to show that
-- End edit --
I have two classes which each contain a pointer to an instance of the other class, but this is creating problems for me . My code is similar to the following
// A.h
#ifndef A_H
#define A_H
class B; // compiler error here
class A
{
B* foo;
// other members and functions
};
#endif
// A.cpp
#include "A.h"
#include "B.h"
/*
declare functions and use methods in both A and B
*/
// B.h
#ifndef B_H
#define B_H
class A;
class B
{
A** bar;
// other stuff
};
#endif
//B.cpp
#include "A.h"
#include "B.h"
/*
declare functions and use methods in both A and B
*/
I was told that forward declaring the other class int he header file then including the other file in the cpp file would work, but on the marked line I get an error that just says "forward declaration of 'struct b'"
Can anyone tell me what I'm doing wrong?
Include one header, let say b.h in a.h. Do not forward declare B in a.h. b.h can stay as it is.
Otherwise you get sth like
class B {};
....
class B;
It is always wise to do preprocessing only on such errors.
SOLVED
What really helped me was that I could #include headers in the .cpp file with out causing the redefined error.
I'm new to C++ but I have some programming experience in C# and Java so I could be missing something basic that's unique to C++.
The problem is that I don't really know what's wrong, I will paste some code to try to explain the issue.
I have three Classes, GameEvents, Physics and GameObject. I have headers for each of them.
GameEvents has one Physics and a list of GameObjects.
Physics has a list of GameObjects.
What I'm trying to achieve is that I want GameObject to be able to access or own a Physics object.
If I simply #include "Physics.h" in GameObject I get the
"error C2111: 'ClassXXX' : 'class' type redifinition" which I understand.
And this is where I thought #include-guards would help so I added an include guard to my Physics.h since that's the header I want to include twice.
This is how it looks
#ifndef PHYSICS_H
#define PHYSICS_H
#include "GameObject.h"
#include <list>
class Physics
{
private:
double gravity;
list<GameObject*> objects;
list<GameObject*>::iterator i;
public:
Physics(void);
void ApplyPhysics(GameObject*);
void UpdatePhysics(int);
bool RectangleIntersect(SDL_Rect, SDL_Rect);
Vector2X CheckCollisions(Vector2X, GameObject*);
};
#endif // PHYSICS_H
But if I #include "Physics.h" in my GameObject.h now like this:
#include "Texture2D.h"
#include "Vector2X.h"
#include <SDL.h>
#include "Physics.h"
class GameObject
{
private:
SDL_Rect collisionBox;
public:
Texture2D texture;
Vector2X position;
double gravityForce;
int weight;
bool isOnGround;
GameObject(void);
GameObject(Texture2D, Vector2X, int);
void UpdateObject(int);
void Draw(SDL_Surface*);
void SetPosition(Vector2X);
SDL_Rect GetCollisionBox();
};
I get multiple issues that don't understand why they're showing up.
If I don't #include "Physics.h" my code runs just fine.
I'm very grateful for any help.
The preprocessor is a program that takes your program, makes some changes (for example include files (#include), macro expansion (#define), and basically everything that starts with #) and gives the "clean" result to the compiler.
The preprocessor works like this when it sees #include:
When you write:
#include "some_file"
The contents of some_file almost literally get copy pasted into the file including it. Now if you have:
a.h:
class A { int a; };
And:
b.h:
#include "a.h"
class B { int b; };
And:
main.cpp:
#include "a.h"
#include "b.h"
You get:
main.cpp:
class A { int a; }; // From #include "a.h"
class A { int a; }; // From #include "b.h"
class B { int b; }; // From #include "b.h"
Now you can see how A is redefined.
When you write guards, they become like this:
a.h:
#ifndef A_H
#define A_H
class A { int a; };
#endif
b.h:
#ifndef B_H
#define B_H
#include "a.h"
class B { int b; };
#endif
So now let's look at how #includes in main would be expanded (this is exactly, like the previous case: copy-paste)
main.cpp:
// From #include "a.h"
#ifndef A_H
#define A_H
class A { int a; };
#endif
// From #include "b.h"
#ifndef B_H
#define B_H
#ifndef A_H // From
#define A_H // #include "a.h"
class A { int a; }; // inside
#endif // "b.h"
class B { int b; };
#endif
Now let's follow the preprocessor and see what "real" code comes out of this. I will go line by line:
// From #include "a.h"
Comment. Ignore! Continue:
#ifndef A_H
Is A_H defined? No! Then continue:
#define A_H
Ok now A_H is defined. Continue:
class A { int a; };
This is not something for preprocessor, so just leave it be. Continue:
#endif
The previous if finished here. Continue:
// From #include "b.h"
Comment. Ignore! Continue:
#ifndef B_H
Is B_H defined? No! Then continue:
#define B_H
Ok now B_H is defined. Continue:
#ifndef A_H // From
Is A_H defined? YES! Then ignore until corresponding #endif:
#define A_H // #include "a.h"
Ignore
class A { int a; }; // inside
Ignore
#endif // "b.h"
The previous if finished here. Continue:
class B { int b; };
This is not something for preprocessor, so just leave it be. Continue:
#endif
The previous if finished here.
That is, after the preprocessor is done with the file, this is what the compiler sees:
main.cpp
class A { int a; };
class B { int b; };
So as you can see, anything that can get #included in the same file twice, whether directly or indirectly needs to be guarded. Since .h files are always very likely to be included twice, it is good if you guard ALL your .h files.
P.S. Note that you also have circular #includes. Imagine the preprocessor copy-pasting the code of Physics.h into GameObject.h which sees there is an #include "GameObject.h" which means copy GameObject.h into itself. When you copy, you again get #include "Pysics.h" and you are stuck in a loop forever. Compilers prevent that, but that means your #includes are half-done.
Before saying how to fix this, you should know another thing.
If you have:
#include "b.h"
class A
{
B b;
};
Then the compiler needs to know everything about b, most importantly, what variables it has etc so that it would know how many bytes it should put in place of b in A.
However, if you have:
class A
{
B *b;
};
Then the compiler doesn't really need to know anything about B (since pointers, regardless of the type have the same size). The only thing it needs to know about B is that it exists!
So you do something called "forward declaration":
class B; // This line just says B exists
class A
{
B *b;
};
This is very similar to many other things you do in header files such as:
int function(int x); // This is forward declaration
class A
{
public:
void do_something(); // This is forward declaration
}
You have circular references here: Physics.h includes GameObject.h which includes Physics.h. Your class Physics uses GameObject* (pointer) type so you don't need to include GameObject.h in Physics.h but just use forward declaration - instead of
#include "GameObject.h"
put
class GameObject;
Furthermore, put guards in each header file.
The issue is that your GameObject.h does not have guards, so when you #include "GameObject.h" in Physics.h it gets included when GameObject.h includes Physics.h.
Add include guards in all your *.h or *.hh header files (unless you have specific reasons to not do that).
To understand what is happening, try to get the preprocessed form of your source code. With GCC, it is something like g++ -Wall -C -E yourcode.cc > yourcode.i (I have no idea on how Microsoft compilers do that). You can also ask which files are included, with GCC as g++ -Wall -H -c yourcode.cc
Firstly you need include guards on gameobject too, but that's not the real problem here
If something else includes physics.h first, physics.h includes gameobject.h, you get something like this:
class GameObject {
...
};
#include physics.h
class Physics {
...
};
and the #include physics.h gets discarded because of the include guards, and you end up with a declaration of GameObject before the declaration of Physics.
But that's a problem if you want GameObject to have a pointer to a Physics, because for htat physics would have to be declared first.
To resolve the cycle, you can forward-declare a class instead, but only if you are just using it as a pointer or a reference in the declaration following, i.e.:
#ifndef PHYSICS_H
#define PHYSICS_H
// no need for this now #include "GameObject.h"
#include <list>
class GameObject;
class Physics
{
private:
list<GameObject*> objects;
list<GameObject*>::iterator i;
public:
void ApplyPhysics(GameObject*);
Vector2X CheckCollisions(Vector2X, GameObject*);
};
#endif // PHYSICS_H
Use include guards in ALL your header files. Since you are using Visual Studio you could use the #pragma once as the first preprocessor definition in all your headers.
However I suggest to use the classical approach:
#ifndef CLASS_NAME_H_
#define CLASS_NAME_H_
// Header code here
#endif //CLASS_NAME_H_
Second read about forward declaration and apply it.
The goal of a header guard is to avoid including the same file many times.
But the header guard that is currently used in C ++ can be improved. The current guard is:
#ifndef AAA_H
#define AAA_H
class AAA
{ /* ... */ };
#endif
My new guard proposal is:
#ifndef AAA_H
#define AAA_H
class AAA
{ /* ... */ };
#else
class AAA; // Forward declaration
#endif
This resolves the annoying problem that occurs when the AAA class needs the BBB class declaration, while the BBB class needs the AAA class declaration, typically because there are crossed pointers from one class to the other:
// File AAA.h
#ifndef AAA_H
#define AAA_H
#include "BBB.h"
class AAA
{
BBB *bbb;
/* ... */
};
#else
class AAA; // Forward declaration
#endif
//+++++++++++++++++++++++++++++++++++++++
// File BBB.h
#ifndef BBB_H
#define BBB_H
#include "AAA.h"
class BBB
{
AAA *aaa;
/* ... */
};
#else
class BBB; // Forward declaration
#endif
I would love for this to be included in the IDEs that automatically generate code from templates.
" #pragma once " ::: serves the same purpose as header guards, and has the added benefit of being shorter and less error-prone.
Many compilers support a simpler, alternate form of header guards using the #pragma directive:
" #pragma once "
// your code here
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, people recommend sticking to traditional header guards. They aren’t much more work and they’re guaranteed to be supported on all compliant compilers.