Avoid cyclic references

Question

I'm building a small game with SDL. I've a class GameObject which is the main class for representing objects in my game. The different behaviors are solved my components you can inject from the outside:

#include "Input.h"
class GameObject
{
public:
    void setInput(Input* input)
    {
        input->setGameObject(this);
        this->input = input;
    }
}


class GameObject; // cannot #include "GameObject.h"
class Input
{
private:
    GameObject* object;
public:
    void update(float elapsedTime)
    {
        // do fancy stuff on the GameObject object
    }
    void setGameObject(GameObject* object)
    {
        this->object = object;
    }
}

The Input class has to work on the GameObject instance. I have a cyclic reference now which is not a good idea I guess?

Edit: I adjusted my example to make it clearer. I have some of these components like the Input class and I've to use this class GameObject; statement since I cannot include the header file. So if I understood it correctly I've a cyclic reference!? To solve that I would have to use an interface and add this to setGameObject(InputInterface* object). But I cannot predict what functions/member are needed for access of the GameObject because there are different components used (e.g. PlayerInput, DemoInput, AiInput, ...).

Answer 1

It seems you're using raw pointers (personally I think this is a bad idea), so I see no problem in having this cyclic reference, just remember to check for null.

If you were using smarter pointer types, in this case you would use a strong reference in one direction (the one that "contains" the other) and a weak reference in the other (the one that only needs a way to communicate).

For example, your game object probably owns the input mechanism; but the input mechanism just needs a way to communicate the input to the game object.

std::weak_ptr is used to break circular references of std::shared_ptr.

See: http://en.cppreference.com/w/cpp/memory/weak_ptr

Also, check if your input really needs a hold on the whole game object, or just some object that has certain interface. In that case, event mechanisms or the delegate pattern could help you remove some hard dependencies.

Answer 2

Cyclic references or two-sided reactivity is not uncommon.

For example, say we have a client/server relationship. Based on changes on the client or the server for, say, a webapp, the server can decide to update the client, or the client can forward an activity or action that the user has taken that requires a client's response. Either way, both might have a reference to the same data or to each other, which requires "references..." or do they? Sometimes, it can be more helpful to decouple the references from the interface to modify the data pointed to by the references.

The general response for this, much like web communications, is asynchronous I/O or message passing, and this is not an unusual pattern in even a game--often times, single-player games can make use of the message-passing model (think SimCity's GlassBox simulation with "agents" or MMORPGs with actual networking messages/packets).

If you're concerned about "coupling," perhaps you should consider various async techniques to prevent classes from having built-in callbacks to other modules that require their definitions; callbacks/reactor functions are a very common occurrence--Boost.Signals2 has a nice example of how this might be used, as well as std::async, I believe. Another option is to simply abstract everything with message passing, much like peer-to-peer networking, and encapsulate each module of your engine with message-passing/receiving modules. This would also make diagnostics easier to implement, provided an external module could "peek" at the metadata of messages.