Public Group

# Always running into a circular dependency

This topic is 1869 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys.

So whenever I try to make a game I run into a problem where a circular dependency occurs between the scene or level holding my game objects and the game objects that need access to the level. I am sure this can be easily solved because my architecture is structured wrong but I just can't seem to think of an efficient solution. I'll roughly show what I have (just the parts that are causing the dependency).

Scene.h

#include "ObjectList.h"

class Scene : public EventListener
{
public:
ObjectList objectList; // This holds all the entities that are currently active in a particular scene/level.
};


ObjectList.h

#include "Entity"

class ObjectList
{
private:
std::vector<Entity*> objectList;
};


Entity.h

#include "Scene.h"

class Entity : public sf::Sprite, public EventListener
{
protected:
Scene *gameWorld;
};
Edited by PragmaOnce

##### Share on other sites

Why does an Entity has to know about the Scene?

##### Share on other sites

Look up guard statements.

#ifndef ENTITY_H
#define ENTITY_H

And at the end of the header:

#endif

##### Share on other sites

Why does the entity need to know about the scene?

Also, you shouldn't be inheriting from sf::Sprite. Make it a member and, if you want to use your class like the sprite, inherit from sf::Drawable and sf::Transformable. You'll need to override the draw method, and there are a few things that the Sprite has that aren't in either of those (color, bounds, and texture/texture rects).

##### Share on other sites

Look up guard statements.

#ifndef ENTITY_H
#define ENTITY_H

And at the end of the header:

#endif

I use #pragma once.

I didn't include it with my examples because it has nothing to do with the problem at hand. Those classes are actually filled with members and methods but I thought I would leave out any code that has nothing to do with the circular dependency, to make the problem easier for others to understand.

Why does an Entity has to know about the Scene?

Because the Scene is going to hold the list of entities found in a particular level. I was thinking I might need it later to implement some logic, for example:

// Inside explosion_object, this is purely psuedo
Explode()
{
}



Also, you shouldn't be inheriting from sf::Sprite

Thanks for the tip on forward declarations. I have read about them but I always thought it was bad practice to do it, but if you say it's fairly common I guess it's a solution

Edited by PragmaOnce

##### Share on other sites

That's why I use
#pragma once

One small thing about #pragma once is that it's technically not part of the standard, and though it's widely supported (I don't think I've ever seen a compiler that doesn't support it) people will often use include guards after the #pragma once, just in case #pragma once isn't supported.

Edited by Samith

##### Share on other sites

I use #pragma once.

I didn't include it with my examples because it has nothing to do with the problem at hand. Those classes are actually filled with members and methods but I thought I would leave out any code that has nothing to do with the circular dependency, to make the problem easier for others to understand.

Since the topic appeared to be circular dependency, making a note about using guards or #pragma once would have contributed to the understanding, as that tends to be one portion of usual circular dependency issues.

##### Share on other sites

That's why I use
#pragma once

One small thing about #pragma once is that it's technically not part of the standard, and though it's widely supported (I don't think I've ever seen a compiler that doesn't support it) people will often use include guards after the #pragma once, just in case #pragma once isn't supported.

Yes, I know it's only a directive for compilers. Since I am a mere novice, working alone, on a project that no one else will see... I figured that if my compiler supports it, it reduces the chance of bugs, and does not involve as much typing :p

I use #pragma once.

I didn't include it with my examples because it has nothing to do with the problem at hand. Those classes are actually filled with members and methods but I thought I would leave out any code that has nothing to do with the circular dependency, to make the problem easier for others to understand.

Since the topic appeared to be circular dependency, making a note about using guards or #pragma once would have contributed to the understanding, as that tends to be one portion of usual circular dependency issues.

Ah I see, forgive my lack of experience. I didn't realize that it could cause dependency issues. Thank you :)

##### Share on other sites

Dragonsoulj, on 29 Nov 2013 - 2:15 PM, said:

PragmaOnce, on 29 Nov 2013 - 2:00 PM, said:

I use #pragma once.

I didn't include it with my examples because it has nothing to do with the problem at hand. Those classes are actually filled with members and methods but I thought I would leave out any code that has nothing to do with the circular dependency, to make the problem easier for others to understand.

Since the topic appeared to be circular dependency, making a note about using guards or #pragma once would have contributed to the understanding, as that tends to be one portion of usual circular dependency issues.

Ah I see, forgive my lack of experience. I didn't realize that it could cause dependency issues. Thank you

Not always the case, but one potential issue. I ran into this a few times myself.

Just a potential thought to this issue, why not just pass the Scene to your Explode function and see if that removes the issue?

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 14
• 14
• 45
• 22
• 27
• ### Forum Statistics

• Total Topics
634044
• Total Posts
3015212
×