Generally when I write software, I try to keep things relatively well organized. Inevitably, however, things are going to get a bit messy, especially if you’re working on a large, disorganized codebase that you didn’t write to begin with… say, oh… something like the Source SDK.
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.
Fixing the Fedora 12 VirtualBox Guest Additions problem
I’m a frequent VirtualBox user, and as I’ve noted in my previous posts, I’m an avid fan of Fedora as well.
However, there is a nasty bug in the most recent version of VirtualBox (3.1.2) when combined with Fedora 12. After installing the Guest Additions kernel modules as per the user docs, the system boots to a black screen with a cryptic error message that looks like a SELinux labeling problem (it’s not).
type=1305 audit(12587840002.571:32444): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:readahead_t:s0 res=1The problem is actually with the Guest Additions video driver, the one that gives you the nice resizable desktop window. Once the driver is built and installed, for some reason the X server can’t find any screens and refuses to start.
Until the bug gets fixed in the video driver, here’s how you can fix the system so that it will boot correctly, although you’ll lose the dynamic resizing ability. You’ll have to stick with fixed, predefined resolutions for now.
cd /mnt/sysimage/etc/X11vi xorg.confSection "Device" Identifier "Configured Video Device" Driver "vboxvideo" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Configured Screen" Monitor "Configured Monitor" Device "Configured Video Device" SubSection "Display" Depth 24 Modes "1440x900" "1680x1050" EndSubSection EndSection Section "InputDevice" Identifier "vboxmouse" Driver "vboxmouse" Option "CorePointer" Option "Device" "/dev/input/mice" EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Configured Screen" 0 0 InputDevice "vboxmouse" EndSectionA huge thanks goes out to Jits in the VirtualBox forums for this fix!