In this particular case, the objects storing a pointer to the scene is redundant and a waste of memory. The scene is implicit in the objects being within the scene. Thus you should pass the scene to the methods of the objects that require the scene.

A potential downside with explicitly passing the scene to the methods is, well, that its explicit. When you store it in the object, the object "implicitly" knows which scene you are talking about, since you set it when creating the object. When you pass the scene as a parameter, the scene is still implicit, except that C++ does not have the capability to implicitly pass the scene, and thus it must be done manually for each and every method call. This might be enough to just keep it as a member variable, since your game code will be less cluttered with fairly redundant information.

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

You shouldn't be inheriting from any classes that don't include a virtual destructor. If you cast the derived object into its base class and call the object's destructor, chances are good that the derived destructor will not be called. That is at least what I learned from Effective C++ :D

Actually, Sprite does have a virtual destructor because sf::Drawable has one. Here are some link on the SFML about inheriting from sf::Sprite.

Nice catch! I checked out Sprite.hpp and didn't see it declare a destructor so I thought it didn't have one.

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

It's quite the opposite. You should use them everywhere you possibly can instead of including headers in headers. This will greatly assist your compilation/iteration times with normal build systems, especially if you also avoid the STL as much as possible. If you habitually use forward declarations and avoid header includes in other headers unless you are forced to you'll find you tend to design better classes, too.

If you want to avoid this circular dependency, you can declare that "scene *gameworld" as "void *miscdata". It'd add up reusability and free you from this circular dependency, under the cost of increased complexity. But you really should rethink your architecture; as a teacher once told me, if programmers can't understand your architecture, it's a bad one. Given that more people asked the same question i would, I am not the only one!

Don't do that! If you delete it through a void* without a cast no destructor will be called! EDIT: plus you need to cast it everywhere you use it unless you are just taking the address EDIT2: And you could cast it to anything you want really with a C-style cast and the compiler will assume you know what you are doing!

Forward declare scene instead.