I have created a functional OOP program that uses a bunch of classes, and I am getting a bunch of errors that don’t make sense. I am working on a Windows VC++ 2008 project, and at the start I tried to have different implementation, and header files. when I tried to for example make a
object1.cpp
#ifndef Object1_cpp
#define Object1_cpp
#include "Object1.h"
Object1::Object1(){
...
}
Object1::~Object1(){
...
}
....
#endif
object1.h
#ifndef Object1_H
#define Object1_h
class Object1{
public: Object1();
public: ~Object1(); // line 39 of object1.h
...
};
#endif
Main.cpp
#include "object1.cpp"
sometimes this returns errors of
1>c:...\object1.h(39) : error C2059: syntax error : '('
1>c:...\object1.h(39) : error C2238: unexpected token(s) preceding ';'
and since it is not complaining about the constructor the only thing that comes to mind would be the ‘~’ indicating the destructor. when I take the .h out of the picture changing the .cpp to be
#ifndef Object1_H
#define Object1_h
class Object1{
public: Object1::Object1();
public: Object1::~Object1();
...
};
#endif
or
#ifndef Object1_H
#define Object1_h
class Object1{
public: Object1();
public: ~Object1();
...
};
#endif
it compiles fine. I don’t understand it. when I have done something similar in the past on other compilers it works fine, but it doesn’t here.
currently the program is fully functional while I ignore the existence of the .h files, and do everything in the .cpp files. it seems like the compiler throws an issue with the Til-de operator denoting the destructor. this is just one example of the problem, and it occurs in all of my classes when I try to split up the implementation, and forward references.
found solution. apparently one of my team mates used the same #define in one of his files (because it made sense but wasn’t the name of the file as convention was required)
Your include guards are broken:
You have a
_Hat the end of one and an_hat the end of the other. This causes the include guard not to work.Also, you don’t need, and don’t want, include guards in your implementation files. They should never be included by anything anyway.