I'm a novice programmer, still in the midst of trying to learn C++ and OOP design basics. The project that I've been working on to teach myself is a C++ game that has multiple classes, files, states, etc. However, I keep running into snags with file organization that range from simply struggling with where to create objects to compile-breaking linker errors.
Here's an example of some of the errors that I've been getting:
1>SMGA.obj : error LNK2005: "class Engine smgaEngine" (?smgaEngine##3VEngine##A) already defined in Engine.obj
1>SplashScreenState.obj : error LNK2005: "class Engine smgaEngine" (?smgaEngine##3VEngine##A) already defined in Engine.obj
1>StateManager.obj : error LNK2005: "class StateManager gameStateManager" (?gameStateManager##3VStateManager##A) already defined in Engine.obj
1>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
I've looked around online and I've seen a lot of ~similar~ problems that involve bad include guards or the inclusion of .cpp files instead of .h files. But I haven't done that in my code, so I'm at a loss.
Now, I'm guessing that the error is telling me that I'm trying to create the smgaEngine object of the Engine class (and the gameStateManager object of the StateManager class) twice, but I'm not sure why...
The thing that stands out about these two objects (smgaEngine and gameStateManager) is that I declared them in their corresponding class' .h files immediately after the class declaration. Could this be the issue? - They're still within the include guards, and I wasn't too sure about where else to put them in my code... Would this sloppy coding be the cause of linker errors?
Here's one of the suspect classes...
#ifndef ENGINE_H
#define ENGINE_H
#include <SDL.h>
#include "Timer.h"
class Engine
{
private:
static const int screenWidth = 480;
static const int screenHeight = 270;
static const int screenBPP = 24;
bool running;
SDL_Surface *mainScreen;
SDL_Event eventHolder;
Timer fpsTimer;
public:
Engine();
~Engine();
void init();
void handleEvents();
void handleLogic();
void handleRender();
void cleanUp();
SDL_Event *getEvent();
SDL_Surface *getMainScreen();
bool isRunning();
void setRunning(bool tempRunning);
} smgaEngine;
#endif
And here's the other one:
#ifndef STATEMANAGER_H
#define STATEMANAGER_H
#include "SplashScreenState.h"
#include <vector>
class GameState;
class StateManager
{
private:
std::vector<GameState*> stateStack;
SplashScreenState *splashState;
public:
StateManager();
~StateManager();
void init();
void changeState( GameState *tempNextState );
void addState( GameState *tempNextState );
void removeState();
//returns the back() element of the stateStack vector..
GameState* getTopState();
void handleEvents();
void handleLogic();
void handleRender();
} gameStateManager;
#endif
I've been trying my best to learn C++ and OOP, but I've really been struggling. It seems that every time I attempt to make clean code with encapsulated classes, I end up with a confusing mess. I'm trying to prevent a high degree of class coupling, but I often end up with either linker errors or a lack of ability to communicate between classes... Is it creation of class instance objects within the header files that is causing these errors or is it something else? And if that is the cause of my linker errors, then where should I be creating these objects?
You have defined two global variables, smgaEngine and gameStateManager in your header files, and you have included those header files in two (or more) source files. So you get multiple definition errors. Include guards don't stop header files being included twice in different source files (how could they?) they stop header files being included twice in the same source file.
You're quite close to the correct answer (at least you have a good understanding of the problem). The right way is this
// header file Engine.h
class Engine
{
};
extern Engine smgaEngine;
// in one source file (say Engine.cpp)
Engine smgaEngine;
What you have now is a declaration in the header file (extern makes it a declaration), but a definition in the source file. You can have as many declarations as you like (as long as they are consistent) but you must have only one definition. So for global variables put declarations in the header file and put a definition in one of the source files.
Related
Is there something special about how an MFC project handles includes?
Here's the scenario. I like to define my class member functions in the h file, instead of splitting up a class between two files.
In Visual Studio I can create an empty Win32 project and do something like this:
main.cpp:
#include "doubleDef.h"
int main()
{
doubleDef t;
t.func();
return 0;
}
doubleDef.h:
#pragma once
class doubleDef
{
public:
int func();
};
int doubleDef::func()
{
return 4;
}
This builds just fine.
If I take doubleDef.h into an MFC dialog project, and add #include "doubleDef.h" to the h file of the main dialog, I get LNK2005, saying that func is already defined, making it seem as if the #pragma once is being ignored.
If I instead include doubleDef.h in the main dialog's cpp file, everything is fine. But in the empty Win32 I can include doubleDef.h "multiple times" by doing this:
Header.h
#pragma once
#include "doubleDef.h"
Header1.h
#pragma once
#include "doubleDef.h"
main.cpp:
#include "Header.h"
#include "Header1.h"
int main()
{
doubleDef t;
t.func();
return 0;
}
That is, it appears #pragma once works as expected (prevents multiple definitions of doubleDef::func()).
If I turn doubleDef into a template class, then the function definition must be in the h file. Likewise, I can make func inline, either by adding the keyword or implicitly by defining it next to the declaration in the class (as in int func() {return 4;}), and then, again the definition must be in the h file.
According to the documentation, the compiler treats inline as more or less optional, so it seems like if I just want to keep everything in the h file, I can just make everything inline.
What gives?
The #pragma once means the file will only be included once per source file. If you have many source files including it, you will still get a copy in each source file.
By declaring a function inline, you tell the compiler it's OK to have multiple copies - as long as those copies are identical.
The usual way of working is to have the declarations in the header file, and the definitions (implementation) in another source file.
P.S. MFC has nothing to do with your problems.
In your simple Win32 project you have one main file that keeps including the same item, basically a no-op. To have multiple of the same include in referenced in the same file does not create a new link.
However with your MFC project you put your header file into mainfrm.h. That file is included in several other files in that project not just the mainfrm.cpp. Essentially creating a new link for each of those other files the main header was included in.
1>MainFrm.obj : error LNK2005: "public: int __thiscall
doubleDef::func(void)" (?func#doubleDef##QAEHXZ) already defined in
MfcTest.obj 1>FileView.obj : error LNK2005: "public: int __thiscall
doubleDef::func(void)" (?func#doubleDef##QAEHXZ) already defined in
MfcTest.obj 1>ClassView.obj : error LNK2005: "public: int __thiscall
doubleDef::func(void)" (?func#doubleDef##QAEHXZ) already defined in
MfcTest.obj 1>OutputWnd.obj : error LNK2005: "public: int __thiscall
doubleDef::func(void)" (?func#doubleDef##QAEHXZ) already defined in
MfcTest.obj 1>PropertiesWnd.obj : error LNK2005: "public: int
__thiscall doubleDef::func(void)" (?func#doubleDef##QAEHXZ) already defined in MfcTest.obj
Take a look at that output. You can see each of the other components that thinks it has that object.
To put it another way your original statement of why does it work for one way and not the other is because the complexity of the second example (MFC) actually includes that header all over the place. If you only want it used by the main form then include it in the cpp for it.
This was already answered before, here is more detailed explanation:
You cannot define a function more than once, unless it is inline
You cannot declare a function more than once in the same file.
You do need to declare functions and classes multiple times if they are referenced in multiple .cpp files.
#pragma once prevents multiple declarations in the same file. It will not prevent multiple declarations in different files. Multiple declarations is exactly what you want and it is why you are including the files in multiple .cpp files in the first place.
class N1 {
public:
//Declaration
//Multiple .cpp files need to know about this class and its members
int foo();
};
//Definition
//should be done once. This should go to .cpp file
int N1::foo() {
return 1;
}
In the above example, compile will work fine in multiple .cpp file. The compile routine does not notice multiple definitions. But the linker notices multiple definitions and complains. You have to move the definition to .cpp file or use inline functions.
class N2
{
public:
int foo();
};
inline int N2::foo()
{ //valid, even if it is repeated in different files
return 1;
}
class N3
{
public:
int foo() //always valid
{
return 1;
}
};
I have a question concerning inlining methods.
I am using a library developed for collision models. One header file responsible for graphic interface contains declaration and implementation of the functions but the functions are not inlined. Therefore, it is impossible to include those functions in several translation units.
As an illustration here is a dummy code I designed for illustration :
LivingBeing.h
#ifndef LIVINGBEING_H
#define LIVINGBEING_H
class LivingBeing
{
public:
LivingBeing(double _size);
void breathe();
private:
double size;
};
//////////////
LivingBeing::LivingBeing(double _size)
{
size = _size;
}
void LivingBeing::breathe()
{
// do something
}
#endif
Forest.h
#ifndef FOREST_H
#define FOREST_H
#include "LivingBeing.h"
class Forest
{
public:
Forest(int _numberLivingBeings);
private:
int numberLivingBeings;
};
#endif
Forest.cpp
#include "Forest.h"
Forest::Forest(int _numberLivingBeings)
{
numberLivingBeings = _numberLivingBeings;
// Call LivingBeing constructor, methods etc...
}
Main.cpp
#include "Forest.h"
int main()
{
Forest forest = Forest(10);
return 0;
}
This code does not compile unless I add the inline keyword in front of the constructor LivingBeing and the method breathe. The error message is :
1>main_test.obj : error LNK2005: "public: __thiscall LivingBeing::LivingBeing(double)" (??0LivingBeing##QAE#N#Z) already defined in Forest.obj
1>main_test.obj : error LNK2005: "public: void __thiscall LivingBeing::breathe(void)" (?breathe#LivingBeing##QAEXXZ) already defined in Forest.obj
1>C:\Users\******\Documents\Visual Studio 2010\Projects\TutorialChronoEngine\Debug\Test_3.exe : fatal error LNK1169: one or more multiply defined symbols found
My question is : what is the drawbacks of inlining methods ? The real library I am using is pretty large, I would like to inline methods from a specific file (in my example it would be LivingBeing.h) so that it is possible to use those methods in several .cpp files. What am I risking by changing the source file as such ?
Thanks a lot
You are defining functions (LivingBeing::LivingBeing and LivingBeing::breathe) in a header, which means there will be a definition in each translation unit that includes that header. This breaks the One Definition Rule (ODR), hence the link error.
You have three options:
Move the function definitions into a source file so they are only defined once; or
Declare them inline to allow multiple identical definitions; or
Move the definitions inside the class definition, which implicitly makes them inline.
what is the drawbacks of inlining methods ?
Possibly increased compilation time and executable size; but you'd need to measure to see whether there's any noticable difference.
A less stable API - client code will need recompiling whenever any inline function changes.
The possibility of accidentally breaking the ODR, for example if a function contains macros which might have different expansions in different translation units.
Just because a method is defined in a "source" file (.c/.cpp) doesn't mean it won't be inlined... link-time operations may perform that optimization. Oppositely, just because a method is declared and implemented as inline in a header file doesn't mean it will be inlined. In general, I define methods in a header file if they are very simple, e.g. int getWidth() const { return width; }, or MyObj* getNext() { return internal_itor ? internal_itor->next : 0; }
I am working in restructuring a former program which relies heavily on a external library
ChronoEngine.lib
I created a new project which holds the same additional include directories, linkers etc... than the former one
I have the following piece of code in a header file
#ifndef DRAW
#define DRAW
#include "physics/CHsystem.h"
class draw
{
public:
// Change size
static void changeSize(int w, int h);
// World definition
static void drawSky(double halfSize, double red, double green, double blue);
static void drawChair() ;
static void drawCDG() ;
static void drawPlane();
// Geometrical definition
static void drawSphere(ChBody* body);
static void drawBox(ChBody* body);
};
#endif
this is the same header file as in the previous project, but here visual studio does not find the definition of ChBody (which is included in the "physics/CHsystem.h" header file definition - this file includes physics/ChBody.h -)
when i right click on ChBody to find the reference, visual studio finds 5 references (1 is the real definition (from ChBody.h), 4 others are forward references in others files from the library)
how can I tell my program to find the real definition of the class ? Apparently, it is not a problem of being linked to the library, but more like a referencing problem
my main.cpp is only printing something to the screen for the time being, and draw.cpp is empty (i haven't defined the function i am declaring in draw.h for the time being)
Thanks
Best
Vincent
Thanks a lot
Actually that was a fairly easy problem to solve
The problem was coming from the fact that the other classes (such as ChBody) were defined in a namespace
therefore, adding
using namespace <the name of the namespace>;
before the definition of the class and after the #include solves this kind of issues.
Thanks
Best
Vincent
I checked out a post similar to this but the linkage was different the issue was never resolved. The problem with mine is that for some reason the linker is expecting there to be a definition for the base class, but the base class is just a interface. Below is the error in it's entirety
c:\users\numerical25\desktop\intro todirectx\godfiles\gxrendermanager\gxrendermanager\gxrendermanager\gxdx.h(2) : error C2504: 'GXRenderer' : base class undefined
Below is the code that shows how the headers link with one another
GXRenderManager.h
#ifndef GXRM
#define GXRM
#include <windows.h>
#include "GXRenderer.h"
#include "GXDX.h"
#include "GXGL.h"
enum GXDEVICE {
DIRECTX,
OPENGL
};
class GXRenderManager {
public:
static int Ignite(GXDEVICE);
private:
static GXRenderer *renderDevice;
};
#endif
at the top of GxRenderManager, there is GXRenderer , windows, GXDX, GXGL headers. I am assuming by including them all in this document. they all link to one another as if they were all in the same document. correct me if I am wrong cause that's how a view headers. Moving on...
GXRenderer.h
class GXRenderer {
public:
virtual void Render() = 0;
virtual void StartUp() = 0;
};
GXGL.h
class GXGL: public GXRenderer {
public:
void Render();
void StartUp();
};
GXDX.h
class GXDX: public GXRenderer {
public:
void Render();
void StartUp();
};
GXGL.cpp and GXDX.cpp respectively
#include "GXGL.h"
void GXGL::Render()
{
}
void GXGL::StartUp()
{
}
//...Next document
#include "GXDX.h"
void GXDX::Render()
{
}
void GXDX::StartUp()
{
}
Not sure whats going on. I think its how I am linking the documents, I am not sure.
The problem is You need to have #include "GXRenderer.h" at the top of both: GXGL.h and also GXDX.h.
The base type must be defined not just declared before defining a derived type.
By the way, the error is a compiling error not linking error.
Edit: About your class type redefinition:
at the top of every header file you should have #pragma once.
The #pragma once directive specifies that the file will be included at most once by the compiler in a build.
You included them all into GXRenderManager.h, meaning that GXRenderManager.h is OK.
But you forgot to include them all into GXGL.cpp and GXDX.cpp. In these .cpp files GXRenderer class is completely unknown.
There are at least two "schools" of #include strategies. One says that header file must include everything that is needed for its own compilation. That would mean that GXGL.h and GXDX.h must include GXRenderer.h. If you followed that strategy, your GXGL.cpp and GXDX.cpp would be OK as they are now.
Another "school" says that header files must not include each other at all, i.e. all inclusions must be done through .cpp files. At first sight one could guess that your GXGL.h and GXDX.h follow that strategy (since you are not including anything into them), but then your GXRenderManager.h looks completely different.
You need to decide which strategy you are trying to follow and follow it. I'd recommend the first one.
I got an error C2504: 'CView' : base class undefined
where CView is not directly my base class from which I am inheriting.
I am inherting mYClass from MScrollView, "for this matter any class which is not actual Base Class is what the point is to be noted down here"
but the error is the C2504. When I have included it in the header where this problem is arising, this problem is resolved.
#include "stdafx.h"
where stdafx.h has #include which contains all the basic class defined...hope this answer resolves everyone who are facing this issue.
I have a header file like so:
#pragma once
#include "gamestate.h"
#include "ExitListener.h"
class InitialGameState : public GameState
{
public:
InitialGameState(Ogre::Camera *cam, Ogre::SceneManager *sceneMgr, OIS::Keyboard *keyboard, OIS::Mouse *mouse, Ogre::Root *root);
~InitialGameState(void);
virtual bool update(Ogre::Real time);
virtual void pause(void);
virtual void start(void);
void keyPressed(const OIS::KeyEvent &e);
void keyReleased(const OIS::KeyEvent &e);
//private:
ExitListener *mFrameListener;
};
The problem with this is that I get the following errors from VC 8:
InitialGameState.h(16) : error C2143: syntax error : missing ';' before '*'
InitialGameState.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
InitialGameState.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
(they all refer to the last line)
I have a class ExitListener.h which is why I don't get the errors
Edit: ExitListener.h:
#pragma once
#include <Ogre.h>
#include <OIS/OIS.h>
#include <CEGUI/CEGUI.h>
#include <OgreCEGUIRenderer.h>
#include "Thing.h"
#include "InitialGameState.h"
using namespace Ogre;
class ExitListener : public FrameListener, public OIS::KeyListener, public OIS::MouseListener
{
public:
ExitListener(OIS::Keyboard *keyboard, OIS::Mouse *mouse, Camera *cam, std::vector<Thing*> &vec):
mKeyboard(keyboard), r(0.09), mContinue(true), mRunningAnimation(false),
mMouse(mouse), mYaw(0), mPitch(0), things(vec), mCamera(cam), mWDown(false), mSDown(false), mADown(false),
mDDown(false)
{
things = vec;
mKeyboard->setEventCallback(this);
mMouse->setEventCallback(this);
}
bool frameStarted(const FrameEvent& evt);
bool keyPressed(const OIS::KeyEvent &e);
bool keyReleased(const OIS::KeyEvent &e);
bool mouseMoved(const OIS::MouseEvent &e);
bool mousePressed(const OIS::MouseEvent &e, OIS::MouseButtonID id);
bool mouseReleased(const OIS::MouseEvent &e, OIS::MouseButtonID id);
void setOwner(GameState *g);
private:
AnimationState *mSwim;
Radian r;
Radian mYaw;
Radian mPitch;
OIS::Keyboard *mKeyboard;
OIS::Mouse *mMouse;
Camera *mCamera;
bool mContinue;
bool mRunningAnimation;
std::vector<Thing*> &things;
bool mWDown;
bool mADown;
bool mDDown;
bool mSDown;
GameState *mOwner;
};
Edit 2:
It turned out that the problem could be solved by a forward declaration and then including the other header directly in my .cpp file.
Thanks.
My guess is that ExitListener.h is including InitialGameState.h header file either directly or indirectly. So there is a circular dependency between the header file and compiler is unable to find the declaration for ExitListener. If you just need to store the pointer of ExitListener in this class then there is no need to include the ExitListener.h header file. Instead you can just use the forward declaration as class ExitListener;
EDIT: You can use the forward declaration as suggested above, or remove the InitialGameState.h include from ExitListener.h . You need to include GameState.h (the base class header file) only. But I prefer to use the forward declarations in header file and include the header file only in cpp.
The errors don't refer to the last line, but to the line before the last line. (Please be precise. If people know the compiler well which emits this error message, their guesses might be a lot better if they know the exact line it is given for.)
"ExitListener.h" is not a class, but a header. (This isn't Java.) One would assume that there is a class ExitListener defined (or at least declared) inside that header, but there could just as well be some other class, none at all, or many classes.
Without this header, it's impossible to say exactly what's wrong, although either circular dependencies between these two headers or a missing ; at the end of the ExitListener class' definition is a very good guess that fits my experience with such errors. At the very least I'm sure the error means that the compiler doesn't know what ExitListener is.
As others have said, you do not need a class definition in order to declare a pointer to that class, so (assuming that "ExitListener.h" defines the ExitListener class) you don't need to include the header at all. A simple forward declaration class ExitListener; is sufficient enough to declare the ExitListener *mFrameListener member. (You will need to include the full class definition in order to implement the InitialGameState member functions that deal with ExitListener, though. If you implement these functions in the header where InitialGameState is defined, you will need to keep that "ExitListener.h" include.)
Apparently the problem is with ExitListener definition, it's not considered valid at that point.
The error is in the ExitListener.h file (or any of the file it includes). Often this problem is due to a missing ; at the end of the class.
If you add the code of this file I will be able to help you further.
The problem
ExitListener was incorrectly declared. This is the only solution for VS to say this.
Check that there was no error when compiling the ExitListener class. (and that you did not forget the trailing ";")
A side note
Here you are using a pointer to ExitListener. You do not need to know the size or internal layout of ExitListener if you just declare a pointer.
A forward declaration would be enough.
I suspect you are missing the Ogre includes somewhere on your include chain.
My assumption is based on the little knowledge I have about your other header files and VC alerting that it's missing a type specifier: missing type specifier.