Frequently you have some class which is composed inside another class, but occasionally needs to access the class it’s composed inside of. Basically, the classes are composed inside each other, though the abstraction really only makes sense in one direction. Confused yet?

In this example, we’ll use a Refrigerator class which stores inside it an instance of a Cheese class. Why cheese, you ask? Because cheese is delicious. Also, our refrigerator is from the future and can slice and serve cheese just like the built in ice maker and water dispenser. It’s a pretty sweet fridge.

Now, we were all taught to keep our #includes in our header files, not the implementation files, so like good little programmers we construct our classes like so:

refrigerator.h

#include "cheese.h"

class Refrigerator {
private:
    Cheese *pCheese;
    int temp = 35;

public:
    void ServeCheese();
    int GetTemp();
};

refrigerator.cpp

#include "refrigerator.h"

void Refrigerator::ServeCheese() {
    printf("Now dispensing %s cheese!\n", pCheese->GetFlavor());
}

int Refrigerator::GetTemp() {
    return temp;
}

cheese.h

class Cheese {
private:
    Refrigerator *pFridge;
public:
    char *GetFlavor();
    void CheckTemp();
    void BeginMolding();
};

cheese.cpp

#include "cheese.h"

void Cheese::CheckTemp() {
    if (pFridge->GetTemp() > 45) {
        BeginMolding();
    }
}

char *Cheese::GetFlavor() {
    return "cheddar";
}

I’ve left out the constructors in this example for brevity, but let’s assume that they get the pointers set up correctly so that our instance of the Refrigerator class has a correct pointer to an instance of the Cheese class and vice versa.

Now, at this point you may be screaming that this needs to be refactored and reorganized. Yes, it probably does. But there are many instances where you simply can’t, and in fact the abstraction really only makes sense one way. The fridge has cheese in it, but the cheese certainly doesn’t have a fridge in it. We just need that pesky reference around so we can check the temperature of the fridge every so often.

(Yes, I am aware that the fridge could push it’s temperature down to all the items in it, ala the Observer Pattern. Yes I am aware that would be a better solution. But this is a contrived example anyway, so stick with me here.)

Now, the code given above doesn’t compile, because the Cheese class has no idea what the heck this Refrigerator class is, so we either need to include it or forward declare it. If we try to do this:

cheese.h

#include "refrigerator.h"

our compiler (more specifically, the preprocessor) is going to get very angry at us, depending on which order it decides to compile refrigerator and cheese. The solution, is a forward delcaration:

cheese.h

class Refrigerator;

class Cheese {
    // ...etc...
};

Basically what this does is tell the compiler, “Hey! There’s this class called Refrigerator that I might talk about, so here’s an empty declaration of it!”

The problem, though, is that this is rather limiting. Within the Cheese class, we can declare pointers to Refrigerator class, no problem. Pointers are of fixed size, so the compiler doesn’t much what care what it’s a pointer to, since it knows how much memory it needs to hold a pointer to it. When we try to access members of the class, though, like properties or methods, it falls apart because as far as the compiler knows, the class is empty. After all, we told it the Refrigerator class didn’t have anything in it.

So if we can’t #include it and forward declaring it doesn’t give us what we want, what can we do?

Well, we can do both. Kind of.

The solution is to forward declare in your header file, and #include in your implementation file. This will avoid the preprocessor headaches of of the chicken and egg #include, while allowing us to access the members of forward declared class in the implementation. In other words, here’s the fix:

cheese.h

class Refrigerator;

class Cheese {
    ...
};

cheese.cpp

#include "cheese.h"
#include "refrigerator.h"

Again, it goes without saying, the better solution is to refactor or rearchitect your code if you can. These kind of hacks can get really out of hand and are usually a good code smell that something needs to be fixed at a deeper level. However, if you’re working on a large codebase that you can’t change, this can help out a lot.

It’s well documented on how you go about spawning entities, but I couldn’t find a good place explaining how to remove spawned entities through code.

Don’t try meddling with the global entity list (gEntList) or calling its RemoveEntity() method. It doesn’t do what you want.

Instead, used one of the super-handy UTIL_* functions. Given a pointer to the entity you want to remove, simply use:

UTIL_Remove(pEntity);

Poof. Entity gone. Remember, entities are created and destroyed on the server side only. The server will automatically broadcast any changes to the entity list to its connected clients for you.