Click here to Skip to main content
14,105,677 members
Rate this:
 
Please Sign up or sign in to vote.
See more:
My problem is that I have a global_variables.h file which needs to know about the files :
- Debugger.h
- Window.h
- Input.h

My problem is that Input.h needs to know about Window.h, and needs to use several of it's functions and therefore it also needs the global_variables.h file, and now I have ran into a circular dependency.

The reason I'm using a Global_Variables.h file is because I knew many files would need to access my different game engine components, so I threw them into the Global_Variables.h file, which seemed like a good idea at first.¨

But, since I'm a beginner i didn't think of this problem that I'm now facing. :/

Here's some code examples :

Global_Variables.h :
#pragma once

#include "Debugger.h"
#include "Window.h"
#include "Input.h"

// The name of the game the engine is currently running.
static const std::string GAME_NAME = "SwEngine Testing";

// The debugging/logging and also error handling component of the engine.
static Debugger global_debugger;

// The window/rendering/graphics component of the engine.
static Window global_window;

// The input component of the engine.
// Handles events such as window closing, keyboard pressing and mouse moving.
static Input global_input;


And the input class is newly created, only has a destructor and a constructor as well as some comments.

So, how should I go about solving this problem? :)

What I have tried:

Have tried googling but haven't really found any good answers on how to solve the problem.
So, I have not really tried anything yet.
Posted
Updated 16-Aug-16 9:54am
Comments
Philippe Mori 16-Aug-16 16:45pm
   
Global_variables.h is a bad idea. It will cause lot of recompilation as it would be used everywhere and depends on many files. Each variable should be declared in the appropriate header file so that say a change in Debugger would only affect source files that do depends on debugger.
Philippe Mori 16-Aug-16 16:46pm
   
Forward declarations and appropriate splitting of files can help avoid loops.

1 solution

Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 1

There's a couple ways to go about it. The traditional old-skool, most compatible way is to use what's called an include guard.

include guard - Wikipedia, the free encyclopedia[^]

Basically, if Window.h needs to make sure Input.h and global_variables.h are in included, but so do other areas of the program, then using guards will ensure the compile only processes what's in the include once.

Also, using #pragma once in all of your headers is another way. Not just in a main file. But this is specific to certain compilers such as Visual Studio, so isn't recommended unless you have no desire to ever switch compilers.
   
Comments
The Shroom 16-Aug-16 16:20pm
   
(Not sure if this is how to reply to an answer at all, I hope it is... lol)
I do use #pragma once in all my headers, but I still seem to have circular dependencies?

Now I'm not sure if this is a circular dependency related error or not...
Is there any way to edit my question so i can add more code?
Jeremy Falcon 16-Aug-16 16:29pm
   
Then you'll find that there's no way of fixing this error without redesigning your application. Global_Variables.h is acting more like a main include file here, which is ok. Just look at it from a broad to narrow perspective and redesign your app... Main Parts of App > Global > Debugger, Window, Input.
The Shroom 16-Aug-16 17:23pm
   
Decided to roll with Singletons instead, seems to work so far. :)
Philippe Mori 17-Aug-16 12:01pm
   
Global variables and singleton are usually considered as bad practice... For large applications, it might cause you a lot of trouble. Code will be written assuming that it can always use a global state might at some point might not be the case anymore (multithreading, multiuser or simply the need for an independant object in specific context).
Thus it is better to understand limitations before starting a large project...
Usually it might be best to use some form of depedencies injection instead.
The Shroom 17-Aug-16 12:33pm
   
Never heard of something called "dependencies injection" before, I'll go ahead and read up on that.
Philippe Mori 17-Aug-16 12:46pm
   
Poor man DI would be that you create Debugger, Window and Input objects at start and then pass them as appropriate to constructors (or functions) that need them.
In real life, sometime you do some compromise but it is always preferable to limit code that directly use global state.
Another reason why you might not want to have too much global state is that if you create another game, you might want to maybe use another implementation for the Input module...
The Shroom 17-Aug-16 15:01pm
   
Oh I see, I guess that would work too.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month


Advertise | Privacy | Cookies | Terms of Service
Web01 | 2.8.190518.1 | Last Updated 16 Aug 2016
Copyright © CodeProject, 1999-2019
All Rights Reserved.
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100