Advertisement Jump to content
Sign in to follow this  
PragmaOnce

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
Share on other sites

 

Look up guard statements.

 

At the start of your header:

#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()
{
    scene.ObjectList.findObjectsInSphere(DamageRadius,variableToStoreObjects)
}


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

Why is that,  please elaborate?

 

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 smile.png

Edited by PragmaOnce

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 smile.png

 

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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!