I have 4 files,
HomeScene.h
HomeScene.cpp
Options.h
Options.cpp
both the *.h files have the other *.h included.
Now I am trying to inherit HomeScene.h in Options.h
class OptionScene : public cocos2d::CCLayerColor,HomeScene
the above line gives so many errors.
class OptionScene : public cocos2d::CCLayerColor
the above line has no errors
I have a static bool var; in my HomeScene.h
which I am trying to use directly in my options scene.
Why do you need to include Options.h in HomeScene.h ? If OptionScene is the type derived from HomeScene, then I don't know why would you need to do that.
In case you just need to declare pointer / reference to the type declared in Options.h, you could use forward declaration.
Options.h
#include "HomeScene.h"
class OptionScene
{
// ...
};
HomeScene.h
class OptionScene; // forward declaration
class HomeScene
{
OptionScene* o;
};
If this is your problem, then this question will help you: When can I use a forward declaration?
Related
I have a question in regards to building a project in C++ with abstract classes.
Suppose you have an abstract class A in a header file and then you have class B in a cpp file to create an object from class A. So far we have:
Class_A.h, Class_B.cpp
Within the Class_B.cpp file, I have included the header Class_A.h.
I want to now create objects of Class_B in a main file, for example: main.cpp. I added the header Class_A.h in main.cpp and when compiled, I get 'Class_B’ was not declared in this scope as an error. All files are in the same directory. I'm not too sure how to fix this or whether or not I am not using abstract classes correctly. All the examples I found online did something along the lines of: defining Class_B inside main.cpp without creating a separate cpp file for Class_B.
Example:
Abstract class: Car.h
Instance of abstract class: Toyota.cpp
main.cpp:
#include 'Car.h'
...
Toyota new_car = new Toyota(...);
Just need to organize your code. There's no hard and fast rules about how that needs to be done, but generally you define classes in header files (.h or .hpp) and implement the class in source files (.cpp). In this situation I would:
Class_A.h
class Class_A
{
public:
virtual void myFunc() = 0; // Class_A is abstract
...
}
Class_B.h
#include "Class_A.h"
class Class_B : public Class_A
{
public:
void myFunc();
...
}
Class_B.cpp
Class_B::myFunc()
{
...
}
main.cpp
#include "Class_B.h"
int main()
{
Class_B myClassB;
myClassB.myFunc();
...
return 0;
}
And of course you need to feed all the source files to your compiler correctly, at least Class_B.cpp and main.cpp in this case.
Currently I have 3 classes, set up like this:
World.h
include "WorldObject.h"
class WorldObject;
class TextObject; // when this is added, compiles fine, but tobj is incomplete when accessed
//(world->tobj->function()). if #include "TextObject.h" is added, numerous errors occur within TextObject.h
class World {
public:
WorldObject* wobj; // works fine
TextObject* tobj; //trying to get this to be functional
};
WorldObject.h
#include "World.h"
class World;
class WorldObject {
public:
WorldObject(World* world){...} // works fine, world can be accessed from world objects
};
TextObject.h
#include "WorldObject.h"
#include "World.h"
class TextObject : WorldObject {
public:
TextObject(World* world) : WorldObject(w){...};
};
How can I use forward declaration so that tobj will be accessible from World.h, as obj is, with no errors? I am also using #pragma once at the beginning of each class. I have attempted to add "class World" to TextObject.h and "class TextObject" to World.h, but none of the seemingly standard procedures are working. Any suggestions?
#include <WorldObject.h> in your .cpp file rather than your header and you can access it from there.
Your header includes are causing circular dependencies, which you avoid through forward declarations.
I would like to split a class implementation into three parts, to avoid that users need to deal with the implementation details, e.g., the libaries that I use to implement the functionality:
impl.cpp
#include <api.h>
#include <impl.h>
Class::Class() {
init();
}
Class::init() {
myData = SomeLibrary::Type(42);
}
Class::doSomething() {
myData.doSomething();
}
impl.h
#include <somelibrary.h>
class Class {
public:
Class();
init();
doSomething();
private:
SomeLibary::Type myData;
}
api.h
class Class {
Class();
doSomething();
}
The problem is, that I am not allowed to redefine headers for the class definition. This does not work when I define Class() and doSomething() only in api.h, either.
A possible option is to define api.h and do not use it in the project at all, but install it (and do not install impl.h).
The obvious drawback is, that I need to make sure, that the common methods in api.h and impl.h always have the same signature, otherwise programs using the library will get linker errors, that I cannot predict when compiling the library.
But would this approach work at all, or will I get other problems (e.g. wrong pointers to class members or similar issues), because the obj file does not match the header?
The short answer is "No!"
The reason: any/all 'client' projects that need to use your Class class have to have the full declaration of that class, in order that the compiler can properly determine such things as offsets for member variables.
The use of private members is fine - client programs won't be able to change them - as is your current implementation, where only the briefest outlines of member functions are provided in the header, with all actual definitions in your (private) source file.
A possible way around this is to declare a pointer to a nested class in Class, where this nested class is simply declared in the shared header: class NestedClass and then you can do what you like with that nested class pointer in your implementation. You would generally make the nested class pointer a private member; also, as its definition is not given in the shared header, any attempt by a 'client' project to access that class (other than as a pointer) will be a compiler error.
Here's a possible code breakdown (maybe not error-free, yet, as it's a quick type-up):
// impl.h
struct MyInternal; // An 'opaque' structure - the definition is For Your Eyes Only
class Class {
public:
Class();
init();
doSomething();
private:
MyInternal* hidden; // CLient never needs to access this! Compiler error if attempted.
}
// impl.cpp
#include <api.h>
#include <impl.h>
struct MyInternal {
SomeLibrary::Type myData;
};
Class::Class() {
init();
}
Class::init() {
hidden = new MyInternal; // MUCH BETTER TO USE unique_ptr, or some other STL.
hidden->myData = SomeLibrary::Type(42);
}
Class::doSomething() {
hidden->myData.doSomething();
}
NOTE: As I hinted in a code comment, it would be better code to use std::unique_ptr<MyInternal> hidden. However, this would require you to give explicit definitions in your Class for the destructor, assignment operator and others (move operator? copy constructor?), as these will need access to the full definition of the MyInternal struct.
The private implementation (PIMPL) idiom can help you out here. It will probably result in 2 header and 2 source files instead of 2 and 1. Have a silly example I haven't actually tried to compile:
api.h
#pragma once
#include <memory>
struct foo_impl;
struct foo {
int do_something(int argument);
private:
std::unique_ptr<foo_impl> impl;
}
api.c
#include "api.h"
#include "impl.h"
int foo::do_something(int a) { return impl->do_something(); }
impl.h
#pragma once
#include <iostream>
struct foo_impl {
foo_impl();
~foo_impl();
int do_something(int);
int initialize_b();
private:
int b;
};
impl.c
#include <iostream>
foo_impl::foo_impl() : b(initialize_b()} { }
foo_impl::~foo_impl() = default;
int foo_impl::do_something(int a) { return a+b++; }
int foo_impl::initialize_b() { ... }
foo_impl can have whatever methods it needs, as foo's header (the API) is all the user will see. All the compiler needs to compile foo is the knowledge that there is a pointer as a data member so it can size foo correctly.
NOTE: Reupload of a question wrongly marked as duplicate
I'm working with Ogre, but my question resides specifically within namespaces.
I haven't been able to find an answer that helps me here.
I'm trying to forward declare Ogre::xyz classes within my header file for a CameraController.
This is the header file
class Ogre;
class Ogre::SceneNode;
class Ogre::SceneManager;
class CameraController
{
private:
Ogre::SceneNode* camNode;
Ogre::SceneManager* scnMgr;
};
This is the cpp file
#include "CameraController.h"
#include <OgreSceneManager.h>
#include <OgreSceneNode.h>
... definitions of functions.
What's the correct way to achieve what I'm trying to do here, in avoiding including unneeded header files within the CameraController.h file
ATTEMPT TO FIX
I attempted the redefinition as marked in a 'duplicate' that talked about declaring classes in namespaces:
namespace Ogre
{
class SceneManager;
class SceneNode;
class Camera;
class Viewport;
class Real;
}
class CameraController
{
private:
Ogre::Real getAspectRatio();
private:
Ogre::SceneNode* camNode;
Ogre::Camera* camera;
Ogre::Viewport* viewPort;
Ogre::SceneManager* scnMgr;
};
EDIT
So the error I am having now is that the classes that I forward declare within the Ogre namespace are being redefined by the headers that I include in the .cpp file
The capitalization of ViewPort and Viewport in the forward declaration is different. C++ would see them as different values.
I can't solve this circular dependency problem; always getting this error:
"invalid use of incomplete type struct GemsGame"
I don't know why the compiler doesn't know the declaration of GemsGame even if I included gemsgame.h
Both classes depend on each other (GemsGame store a vector of GemElements, and GemElements need to access this same vector)
Here is partial code of GEMELEMENT.H:
#ifndef GEMELEMENT_H_INCLUDED
#define GEMELEMENT_H_INCLUDED
#include "GemsGame.h"
class GemsGame;
class GemElement {
private:
GemsGame* _gemsGame;
public:
GemElement{
_gemsGame = application.getCurrentGame();
_gemsGame->getGemsVector();
}
};
#endif // GEMELEMENT_H_INCLUDED
...and of GEMSGAME.H:
#ifndef GEMSGAME_H_INCLUDED
#define GEMSGAME_H_INCLUDED
#include "GemElement.h"
class GemsGame {
private:
vector< vector<GemElement*> > _gemsVector;
public:
GemsGame() {
...
}
vector< vector<GemElement*> > getGemsVector() {
return _gemsVector;
}
}
#endif // GEMSGAME_H_INCLUDED
Remove the #include directives, you already have the classes forward declared.
If your class A needs, in its definition, to know something about the particulars of class B, then you need to include class B's header. If class A only needs to know that class B exists, such as when class A only holds a pointer to class B instances, then it's enough to forward-declare, and in that case an #include is not needed.
If you deference the pointer and the function is inline you will need the full type. If you create a cpp file for the implementation you can avoid the circular dependecy (since neither of the class will need to include each others .h in their headers)
Something like this:
your header:
#ifndef GEMELEMENT_H_INCLUDED
#define GEMELEMENT_H_INCLUDED
class GemsGame;
class GemElement {
private:
GemsGame* _gemsGame;
public:
GemElement();
};
#endif // GEMELEMENT_H_INCLUDED
your cpp:
#include "GenGame.h"
GenElement::GenElement()
{
_gemsGame = application.getCurrentGame();
_gemsGame->getGemsVector();
}
Two ways out:
Keep the dependent classes in the same H-file
Turn dependency into abstract interfaces: GemElement implementing IGemElement and expecting for IGemsGame, and GemsGame implementing IGemsGame and containing a vector of IGemElement pointers.
Look at the top answer of this topic: When can I use a forward declaration?
He really explains everything you need to know about forward declarations and what you can and cannot do with classes that you forward declare.
It looks like you are using a forward declaration of a class and then trying to declare it as a member of a different class. This fails because using a forward declaration makes it an incomplete type.