I'm having a problem with Eclipse's indexing. Here's a minimal working example.
I create a header file, Parent.h, in which I define the following virtual class:
class Parent
{
protected:
virtual ~Parent() {}
public:
virtual void OverrideMe() = 0;
};
Then, I create another header file, Child.h:
#include "Parent.h"
class Child : public Parent
{
};
Immediately, Eclipse complains that "Symbol Parent could not be resolved."
The problem magically goes away if I create a source file Parent.cpp and in it put #include "Parent.h". More strangely, it does not reappear if I delete this source file.
There seems to be something crazy going on with Eclipse's indexing? People with similar problems have recommended doing an "Index -> Rebuild". This does not work for me.
Any help is appreciated. Thanks in advance.
Related
First: My English is not that good yours is. Excuse me.
I'm using Ubuntu (I don't know if this is important) and I had issues with Code::Blocks since I started to use it. But I fixed them by re-opening the program. But now, I get a really crazy error when compiling the code. I included a file just like usual:
#include "GameObjectUtility.h"
and I used the class "GameObjectUtility" to declare a member object, just like this:
class GameObject
{
std::vector<GameObjectUtility> uts;
// Error here:
// GameObjectUtility was not declared in this scope
}
So, is this my fault or is there something buggy with Code::Blocks?
And, additionally, is there a way of saying to the Linker: First execute this file and then the other?
Thank you for your answers!
EDIT: .h and .ccp file GameObjectUtility:
So this is GameObjectUtility.h:
#ifndef GAMEOBJECTUTILITY_H
#define GAMEOBJECTUTILITY_H
#include <string>
#include "Collision.h"
class GameObjectUtility
{
public:
GameObjectUtility();
virtual ~GameObjectUtility();
virtual void Update() = 0;
virtual void LateUpdate() = 0;
virtual void FixedUpdate() = 0;
static void SendMsg(std::string msg);
protected:
private:
virtual void GetMsg(std::string msg) = 0;
};
#endif // GAMEOBJECTUTILITY_H
And in GameObjectUtility.cpp are just two empty definitions of constructor and destructor
Since class GameObjectUtility is pure virtual, you cannot instantiate it.
You can only store std::vector<GameObjectUtility*> in class GameObject.
I have a question regarding hidinging interface details in C++ libraries. The problem is ilustrated with the following example:
Let's say w have a class called ISystem which exposes methods like Init, Run, Tick, Shutdown, GetXXXSubSystem.
Where X are pointers various interfaces like: ISoundSystem, IInputSystem
We also have concrete implementations of ISystem like:
Win32System, OSXSystem etc.
These specific implementations use a pimpl idiom to hide internals
and for example Win32System instantiates Win32RawInputSystem
as input system manager.
All such managers do have their own Init, Run, Tick and Shutdown methods
which are not part of the interface (only concrete implementation) and these are run and managed by the concrete system implementation.
The user calling GetXXXSubSystem gets interface pointer without those methods (Init etc..) but
still he could cast the pointer he gets to concrete implementation
and trigger methods like Init Run Tick etc. which he shouldn't have access to.
The question is, is it possible to hide the concrete class somehow? I tried to make those methods
protected in the concrete implementations and template the class on type which would eventually be friend but this appears to be prohobited and existing hacks do not work with VC11.
The only way I can think of right know is to transfer the concrete implementation declaration from header
into the cpp file of Win32System class but I see ahuge drawback of doing this (even not sure if this would work), because this way each subsystem
would have to be also part of this cpp file and it would become a maintainability nightmare.
Another solution I am thinking about is using factory method like
(RawInput.h)
IInputSystem* CreateRawInputSystem();
(RawInput.cpp)
class RawInput : public IInputSystem {}; ...
and move definition of the class to cpp file but then, how I would acces this type from other parts of my library (ie in Win32System impl)?
Is it possible to include .cpp files form other .cpp files?
Thanks in advance for any tips.
If you're developing a library here, then you can simply choose not to export the header files of the concrete classes that you do not want to expose. You cannot cast to a class of which you do not have a definition.
Example :
MyProjectFolder/Src/Export/ISystem.h
#ifndef ISYSTEM_H
#define ISYSTEM_H
#include "IInputSystem.h"
class ISystem
{
public:
virtual ~ISystem() {};
virtual void Run()=0;
virtual IInputSystem* GetInputSystem()=0;
};
#endif
MyProjectFolder/Src/Export/IInputSystem.h
#ifndef IINPUTSYSTEM_H
#define IINPUTSYSTEM_H
class IInputSystem
{
public:
virtual ~IInputSystem() {};
virtual void Foo()=0;
virtual void Bar()=0;
};
#endif
MyProjectFolder/Src/Export/Win32System.h
#ifndef WIN32SYSTEM_H
#define WIN32SYSTEM_H
#include "ISystem.h"
class Win32System : public ISystem
{
public:
Win32System();
virtual void Run();
virtual IInputSystem* GetInputSystem();
private:
struct impl;
impl* m_pImpl;
};
#endif
MyProjectFolder/Src/Win32RawInputSystem.h
#ifndef WIN32RAWINPUTSYSTEM_H
#define WIN32RAWINPUTSYSTEM_H
#include "IInputSystem.h"
class Win32RawInputSystem : public IInputSystem
{
public:
virtual void Foo();
virtual void Bar();
virtual void Run(); // you do not want to expose that function
};
#endif
MyProjectFolder/Src/Win32System.cpp
#include "Win32System.h"
#include "Win32RawInputSystem.h"
struct Win32System::impl
{
Win32RawInputSystem inputSys;
};
Win32System::Win32System()
: m_pImpl(new impl)
{
}
void Win32System::Run()
{ // run run run
}
IInputSystem* Win32System::GetInputSystem()
{
return &m_pImpl->inputSys;
}
So when building your project its include search path is not only Src/ but also Src/Export/. From within your library project you can use all classes, including Win32RawInputSystem. When deploying your library you only give away those headers that reside in the Src/Export/ folder. Clients can still use the library, but they can never cast IInputSystem* to Win32RawInputSystem* because they do not have that header. Therefore the users of that library can invoke Foo() and Bar() on the IInputSystem*, but they'll never be able to invoke Run().
I am trying to add a class which holds the object of the gui. The file is COptimataModulDlg, and the new class I want to add is Manager.
I've tried writing this and it didnt work:
//Manager.h
#pragma once
class Manager
{
public:
Manager();
~Manager();
private:
COptimataModulDlg omg; //the problem is with this line
};
it works only when I move this line to manager.cpp and I don't understand why.
You probably didn't #include the file where COptimataModulDlg is defined in Manager.h? Maybe it is included in manager.cpp?
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.
My CGameStateLogo which inherit from CGameState:
CGameState.h
#pragma once
#include "GameMain.h"
#include "MyBitmap.h"
class CGameMain;
class CMyBitmap;
class CGameState
{
public:
CMyBitmap* pbmCurrent;
CGameMain* pGM;
int GameStateID;
virtual void MessageEnter () = 0;
virtual void MessageUpdate( int iKey ) = 0;
virtual void MessagePaint( HDC* pDC ) = 0;
void StateHandler ( int msg, HDC* pDC, int key );
public:
CGameState(void);
~CGameState(void);
};
After creating and finding, problem comes from here :
I've created 2 classes: CTest and CGameStateLogo
#pragma once
#include "GameState.h"
class CTest:CGameState
{
public:
CTest(void);
~CTest(void);
};
#pragma once
#include "GameState.h"
class CGameStateLogo:CGameState // Bug at this line
{
public:
CGameStateLogo(void);
~CGameStateLogo(void);
};
Do VS has problem in naming ?
Thanks for reading this :). Things go WEIRD, I'll update my question later. Sorry for wasting your time .
pGameStates.push_back( (CGameState*)gameLogo );
Since CGameStateLogo inherits publically from CGameState, the cast is unneccesary. Upcasts are implicit. Simply write
pGameStates.push_back( gameLogo );
instead.
This does probably not solve your compile troubles, though. As to that, you seem to be mixing up GameState.h and CGameState.h. If that's an actual error in your code, instead of just a copy/paste mistake while writing your question, it could cause this problem.
It could also be that there is some circular dependency problem in your headers. You write
#include "GameState.h"
which should define the GameState class, unless the file has already been included once, but the class definition has not yet been read. This could happen for example in this way:
Some .cpp file includes GameState.h.
GameState.h includes GameMain.h.
GameMain.h includes GameStateLogo.h.
GameStateLogo.h includes GameState.h, but this has already been included, so the include is ignored due to #pragma once.
Generally, such circular dependencies in header files are a thing to avoid.
CGameStateLogo.h is including GameState.h and not CGameState.h. Is it possible you have a file called GameState.h on the include path (and hence you wouldn't get an error about not being able to include GameState.h)?