Current program layout. The left operand includes the right one.
source.cpp
app.hpp // Also includes SFML libraries with sf namespace
game.hpp
ball.hpp
brick.hpp
plate.hpp
The implementation of ball class (ball.cpp) throws a lot of errors "sf does not name a type".
source.cpp
#include "app.hpp"
int main () {
App app(640, 480, "Arkanoid");
while (app.getWindow()->isOpen()) app.run();
return 0; }
app.hpp
#ifndef ArkanoidApp
#define ArkanoidApp
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include "game.hpp"
// code
#endif
game.hpp
#ifndef ArkanoidGame
#define ArkanoidGame
#include "ball.hpp"
#include "brick.hpp"
#include "paddle.hpp"
// code
#endif
ball.hpp
#ifndef ArkanoidBall
#define ArkanoidBall
class Ball
{
public:
Ball(void);
void draw(void);
public: // Setters & getters
private: // Variables
sf::CircleShape circle; // sf is not a class type
sf::Vector2i position; // sf is not a class type
sf::Vector2f direction; // sf is not a class type
private: // Constants
int RADIUS = 8;
int VELOCITY = 6;
};
#endif
Well if your app.hpp includes the sf, of course ball.cpp wouldn't know about it and throw an error, you would need to include the sf inside the ball.cpp as well.
To avoid multiple definitions use #pragma once in your header files.
Other then that it's unclear what and why are you trying to do, if you get to a point where files should include each other it's not a very good design and should be avoided, best design is a tree one.
edit:
For now you can just include the library in every header that requires it (app, ball...).
But you may try something more complicated like MVC. And since it's a graphics library you can create a View and write all your view management there, like opening the window drawing the model etc..
What you do in MVC is a complete separation between model(game, ball) and the view, since you can display the model in different ways, one in 2D and another in 3D, each may use different library and view but the model is still the same.
There are a lot of designs and no correct one, as long as it easy to understand and maintain/add features it's a good design.
Related
This is my first question, so I apologize in advance for any things about stack overflow that I may not be aware of!
The issue I am having is that I am making a simple SDL program, currently it is just supposed to draw a PNG image (Assets/Board.png) to the screen, but I am being faced with many errors to do with the two classes communicating with each other, I think that I have circular inclusion errors. But I have been trying to fix the problem for days and I haven't been able to solve it.
Here are the errors that I am getting:
http://imgur.com/gallery/vq3XLwU/new
(Here is a text version of it, but the formatting is bad sorry)
1>d:\code\c++\games\chess\chess\manager.h(41): error C2079: 'Manager::Tex' uses undefined class 'Render'
1>d:\code\c++\games\chess\chess\render.h(32): error C2146: syntax error : missing ';' before identifier 'manager'
1>d:\code\c++\games\chess\chess\render.h(32): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\code\c++\games\chess\chess\render.h(32): error C2146: syntax error : missing ';' before identifier 'manager'
1>d:\code\c++\games\chess\chess\render.h(32): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
(I have used an image because the formatting of the image is easier to read.)
(Also click on the image in imgur to see the zoomed in version)
You can download the entire code project here (ZIP FILE):
https://www.mediafire.com/?og21315fc1d58sk
But here is the code that I think is causing the issues:
(Manager.h file)
//Include guards.
#pragma once
//Headers.
#include "Render.h"
//Librarys.
#include <SDL_image.h>
#include <string>
#include <SDL.h>
//Namespaces.
using namespace std;
//Enumerator.
enum State { Play, Exit };
class Manager
{
public:
Manager(); //Constructor.
~Manager(); //Destructor.
//Rendering.
SDL_Window* Window;
SDL_Surface* Screen;
SDL_Renderer* Renderer;
//Functions.
void Run();
void Init();
void Close();
void Input();
void Update();
void Error(string);
//Game variables.
State state;
Render Tex;
private:
//Constant values.
const int WINDOW_POS_X = SDL_WINDOWPOS_CENTERED;
const int WINDOW_POS_Y = SDL_WINDOWPOS_CENTERED;
const int INIT_FLAGS = SDL_INIT_VIDEO;
const int SCREEN_HEIGHT = 600;
const int SCREEN_WIDTH = 600;
};
(And here is the Render.h file)
//Include guards.
#pragma once
//Headers.
#include "Manager.h"
//Librarys.
#include <SDL_image.h>
#include <string>
#include <SDL.h>
//Namespaces.
using namespace std;
class Render
{
public:
Render(); //Constructor.
~Render(); //Destructor.
//Functions.
void Draw(int, int); //Draws texture at position.
void Load(string); //Loads texture from path.
void Deallocate(); //Destroy texture.
//Getter functions.
int GetHeight() { return Height; };
int GetWidth() { return Width; };
private:
SDL_Texture* Texture; //Actual image.
Manager manager; //Manager class.
int Height; //Height of image.
int Width; //Wdith of image.
};
So in conclusion, I am having errors related to the class objects, which I believe are being caused by circular inclusion, despite my research I have not been able to fix these issues. I would greatly appreciate any help with this issue.
P.S I know I am not supposed to use the std namespace, instead I must write std::foo, I am aware, so please don't comment about it!
In C++ "ownership" is a very important concept. A class "owns" its members. The problem is you have two objects and you've told the compiler that both "own" the other, which won't do. You have to decide which of them owns the other, and has it as a member (or maybe neither owns the other). At least one class must refer to the other, rather than listing it as a child/member. And the best sort of reference is a pointer.
class Manager;
// this forward declaration tell the compiler the class exists, but
// we don't care about the details yet, so we won't include the header.
// if we try to include it, that header refers to Render, which the compiler
// hasn't seen yet, so the compiler will fail.
class Render
{
public:
Render(Manager* parent_); //Constructor.
...stuff...
Manager* parent;
};
Cpp file:
#include "manager.h"
#include "render.h"
Render::Render(Manager* parent_)
: parent(parent_)
{}
SUGGESTIONS:
1. Eliminate the "Render.h" include:
There doesn't seem to be anything in "Manager.h" that needs anything in "Render.h" - so why include it?
Similarly, 2. Eliminate the "Manager.h" include.
You can simply use a "forward declaration", instead of including the whole class interface (.h file).
These links might help:
C++ circular include
Headers and Includes: Why and How
Okay, I think that I have solved the problem, thanks to a variety of comments. The solution may not be ellegant but it works. Instead of defining the Render Tex variabel inside the Manager header, I declared it inside the Manager.cpp class. Once I had done that I can #include "Render.h" inside the Manager .cpp file. I dont know if that explanation is clear but here is the top of the manager.h file:
//Include guards.
#pragma once
//Librarys.
#include <SDL_image.h>
#include <string>
#include <SDL.h>
And here is the top of the Manager.cpp file:
//Header.
#include "Manager.h"
#include "Render.h"
//Librarys.
#include <iostream>
//Objects.
Render Tex;
I'm trying to create a game in C++.
It has a "Session" class that kind of manages everything. It contains things like a GraphicsManager, a SoundManager, and the current world. It also contains a static pointer to an instance of itself. This way, I want the world to be available for the GraphicsManager so it can be rendered, for example.
Here is a simplified version of my code:
main.ccp
#pragma once
#include "Session.h"
int main() {
Session::getSession()->run(); //Starts a new session and runs it
return 0;
}
Session.h
#pragma once
#include "GraphicsManager.h"
#include "World.h"
class Session; //Forward declaration so it can have a pointer to itself
class Session {
private:
Session();
static Session* s;
World* w; //Pointer because no world is loaded at the beginning of the program
GraphicsManager gm; //Required right away
public:
~Session();
void run(); //Actually launches the game after preparation; not further declared in this example
World* getWorld(); //Returns the pointer to the current world
static Session* getSession();
}
Session.cpp
#include "Session.h"
Session::Session(): gm(GraphicsManager()) {}
Session* Session::getSession() { //Return an instance of Session. If no instance exist yet, create one.
if(s == NULL) s = new Session();
return s;
}
World* Session::getWorld() {return w;} //Returns a pointer to the current world
GraphicsManager.h
#pragma once;
class GraphicsManager {
private:
void render();
public:
void run(); //Calls the render method repeatedly; no further declaration in this example
}
GraphicsManager.cpp
#include "GraphicsManager.h"
void GraphicsManger::render() {
World* w = Session::getSession()->getWorld(); //Get pointer to current world so it can be rendered
}
The render method is where I'm stuck. If I put #include "Session.h" into the GraphicsManager.h file, it gives me an error because apparently two header files cannot include each other. If I put a forward declaration at the beginning of GraphicsManager.h or GraphicsManager.cpp, Visual Studio tells me that incomplete types are not permitted.
This has been giving me a headache for weeks. I've made games in Java before and there this pattern was accepted. So how can I do this? If this structure is not possible in C++, do you have other suggestions for it?
In GraphicsManager.cpp, the compiler needs to know about the Session, so you have to #include "Session.h" which by the way includes GraphicsManager as well as World.
A forward definition will not be sufficient, as the compiler would not be able to check types of getSession()->getWorld() expression.
Apparently your GraphicsManager.h doesn't rely itself on the other definitions, so there should'nt be an issue here.
Try to include Session.h to GraphicsManager.cpp:
#include "Session.h"
void GraphicsManger::render() {
World* w = Session::getSession()->getWorld(); //Get pointer to current world so it can be rendered
}
This way Session class defenition will be visible for compiler in GraphicsManager.cpp, so it will not generate incomplite type error. On the other hand, Session.h is not included to GraphicsManager header, so there will no problem that both headers include each other.
While trying to make a simple game, I've run in to a circular dependency problem.
I searched on the internet and found that forward declaring could fix it, but... Both of my classes depend on a static value.
Is there any easy way to fix, perhaps to forward declare the static values, or do I have to rewrite the core of my game?
2ND EDIT: Looks like I was wrong, the error's still there even after removing almost everything:
main.cpp:
#include "App.h"
//Start the app
int main(int argc, char* args[]){
App App;
return App.on_execute();
}
App.h:
#ifndef APP_H
#define APP_H
#include "Object.h"
class App
{
public:
//Runs when the program starts
int on_execute();
};
#endif // APP_H
App.cpp:
#include "App.h"
int App::on_execute(){
return 0;
}
Object.h:
#ifndef OBJECT_H
#define OBJECT_H
#include <string>
#include <vector>
#include <stdio.h>
#include <SDL.h>
#include <math.h>
#include "Entity.h"
class Object
{
public:
Object(int character, int x, int y, std::string name, SDL_Color color, bool blocks);
//Object vector
static std::vector<Object*> objects;
};
#endif // OBJECT_H
Object.cpp:
#include "Object.h"
std::vector<Object*> Object::objects;
Object::Object(int character, int x, int y, std::string name, SDL_Color color, bool blocks){
}
Entity.h:
#ifndef ENTITY_H
#define ENTITY_H
#include "Object.h"
#include <sdl.h>
class Entity : public Object
{
public:
Entity(int character, int x, int y, std::string name, SDL_Color color, bool blocks, int hp, int power, int defense);
};
#endif // ENTITY_H
Entity.cpp:
#include "Entity.h"
Entity::Entity(int character, int x, int y, std::string name, SDL_Color color, bool blocks, int hp, int power, int defense) : Object(character, x, y, name, color, blocks){
}
I think the design of your code may need to be reworked.
First of all, I'd really discourage you from using non-primitive, non-trivial class statics where possible, whether class static or global static. Non-trivial static classes will have an explicit constructor call before main, and will need to register a destruction to be called after main. The relative ordering of these things is undefined. Worse, if you have a library structure later such that the assembly from the same .cpp file shows up twice, weird things can happen where two copies of the object get constructed, but the same one is destroyed twice.
Second, some of the information is unclear. For example, you claim that the Map class has a static member of type Map. I really don't think this is possible; the static Map member will also have an object of type map, and so on. Similarly with the vector of Objects declared inside Object. Maybe in both these cases you mean inside the file Map.cpp or Object.cpp, as opposed to literally inside the class?
Third, be clear on what forward declaration gives you. It makes the compile aware that something exists, nothing more. It lets you have pointers and references to that type. You cannot create an object or even declare a member variable of a forward declared type, because the compiler doesn't know the size of the forward declared object. You can't use its methods because the compiler doesn't know they exist.
Fourth, you didn't talk about your header files at all. It's only a circular dependency if Map.h requires Object.h, and vice versa. Two header files can't both include each other. On the other hand, the implementation is in Map.cpp and Object.cpp, both of these files can include both Map.h and Object.h. However, personally I prefer to avoid having mutually dependent classes.
What I'd probably suggest is that a Map should own the Objects present on that map. The pattern right now with Map accessing this global is not a good one. Instead of having objects be a global, make std::vector objects a member of the Map class. Notice that if you decide to have multiple Maps later, this works much better, each Map will own the Objects located on that map. The current design doesn't work well if there's more than one Map.
You can then implement move_to as a method not of Object, but rather of Map. Map::move_to(i, dx, dy) moves the ith Object.
I have been trying to write my own state machine where each state is a seperate class derived from a state base class.
Whereever I include my state_t class file (#include "state_t.h") I want all the derived state class headers to be included as well so I don't have to include them all seperatly each time I need to use the state machine or create a new state.
since "state_t" is not defined until the end of state_t.h I can only include my state files at the end of the file state_t.h. I have never written code that does this before and it seems a little odd! I could add a top-level "statemachine.h" which collects all the files together, but it seems a waste.
My question is: is it correct/safe/ok to do this? any draw-backs/issues?
Note: at the moment my code is all test code and its written in Qt, but it should be a straight-up c++ question.
Here is my base class (state_t.h) - notice the #include's at the end:
#ifndef STATE_T_H
#define STATE_T_H
#include <QByteArray>
#include <QDebug>
class state_t
{
public:
state_t(QByteArray stateName);
virtual ~state_t();
virtual state_t * processState(int input) = 0;
QByteArray getState();
QByteArray name;
};
#include "teststate1.h"
#include "teststate2.h"
#endif // STATE_T_H
Here is a state derived class (teststate1.h):
#ifndef TESTSTATE1_H
#define TESTSTATE1_H
#include "state_t.h"
class testState1 : public state_t
{
public:
testState1();
state_t *processState(int input);
};
#endif // TESTSTATE1_H
Here is my main.cpp:
#include <QCoreApplication>
#include <QDebug>
#include "state_t.h"
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
state_t *myState = new testState1();
myState = myState->processState(1);
myState = myState->processState(2);
myState = myState->processState(3);
myState = myState->processState(1);
return a.exec();
}
Note: the code all works perfectly, its really a question of "correctness".
Given your particular example:
It is a bad idea. You introduce a very tight coupling between base and derived types in the wrong direction. A base class should know nothing about its derived types. That is one of the things that allows it to be an effective base class. In your current scheme, every time you write a derived type, you would have to touch the header of the base, forcing a compile time dependency on all client code of the base. Besides that, you have a cyclic include dependency.
In general:
In non-pathological cases, it depends on the situation. Concerning header files, one could argue that it is good to know which headers are required by a file, in which case it makes sense for them to be at the top. However, if the includes are considered to be implementation details that would only be a distraction, they could be placed at the bottom. In my experience this applies specifically to the implementation of template code, and implementation of helper classes and inline functions in anonymous namespaces.
Personally, I'd much rather have all the includes at the top. You can use forward declarations in your other headers to get around the define order issue.
But that's just a style thing - "correctness" wise, there's no reason why you can't do that. You can validly include anything anywhere you like, it's just likely to cause confusion later!
According to me, this is just a convention, as everybody do that, a standard dev will not take a look at the end of the file if he need to add some, and this will be a mess with some includes at the top and some at the bottom.
I prefer to have my includes at the top otherwise it could be a bit confused. My suggestion for you is do not include teststate1.h and teststate2.h in test_t.h instead create state_all.h
#include "state_t.h"
#include "teststate1.h"
#include "teststate2.h"
And include state_all.h instead of state_t.h where you need it
I'm gonna go C++ über n00b on this one and ask how is the best way to deal with a circular dependency when you have inheritance.
The set is simple: Scene class extends Actor; Scene has a pointer to a vector of Actors; Actor has a pointer for (parent) Scene.
As for include files I got:
Scene.h:
#include <string>
#include <vector>
using namespace std;
#ifndef __Scene_h__
#define __Scene_h__
#include "Actor.h"
namespace myns
{
// class Actor;
class Scene;
}
namespace myns
{
class Scene: public myns::Actor
{
/* private class attributes... */
public:
/* public class attributes... */
std::vector<myns::Actor*> actors;
Scene(/* arguments */);
/* public class methods... */
};
}
#endif
Actor.h
#include <string>
#include <vector>
using namespace std;
#ifndef __Actor_h__
#define __Actor_h__
#include "Scene.h"
namespace myns
{
// class Scene;
class Actor;
}
namespace myns
{
class Actor
{
/* private class attributes... */
public:
/* public class attributes... */
myns::Scene* scene;
Actor();
Actor(/* arguments */);
/* public class methods... */
};
}
#endif
But this gives me alot of C2504 errors/base class undefined on Visual Studio 2010.
If I comment the Scene.h include on the Actor.h and uncomment the forward declaration of Scene on Actor.h it works, but then, in my app, if I want to include only the Actor.h on a particular piece of code, it will not work. How can I put this to work while maintaining the inclusion independence for Actor.h - including Actor.h without the need of previously manually including Scene.h?
What is wrong with my class definitions and how is the best way to deal with this circular dependency?
Shouldn't the #ifndef directives prevent this inclusion problem?
Thanks in advance.
but then, in my app, if I want to include only the Actor.h on a particular piece of code, it will not work
What you need to do is in the .cpp file where you need to use define the Actor class you must include both Actor.h and Scene.h. That way the forward declaration will be resolved and everything should work.
As an aside, you should move your #ifndef and #define right to the top of the file, before the includes. Also, having a using in a header file is bad practice because other files that include your header might not work properly. It should be ok to put it inside your namespace myns { ... } though.
Is a Scene really a type of Actor?
If it is, Actors probably shouldn't know about Scenes. Base classes shouldn't usually know about their derived classes.
Where is the Liskov Substitution Principle here? What action do you perform on an Actor that would be polymorphically performed differently by a Scene.
In any case, Scene derives from Actor so must include its base class. But in Actor.h if you really do need the Scene class it must be a forward declaration only.
In the compilation units (the .cpp files) you might include both headers if required.