In my own emulator (higan), I have a namespace for each emulated system, and each component is its own unique object. Example:
namespace GameBoyAdvance {
CPU cpu;
PPU ppu;
Cartridge cartridge;
...
}
The obvious "proper" way would be something like:
class GameBoyAdvance {
CPU cpu;
PPU ppu;
...
};
So you think something like:
class GameBoyAdvance {
CPU cpu{this}; //hooray C++11, this would be
PPU ppu{this}; //much nastier in C++98
...
};
void PPU::scanline() {
cpu.raiseInterrupt(Interrupt::VerticalBlank);
}
void PPU::scanline() {
gameBoyAdvance->cpu.raiseInterrupt(Interrupt::VerticalBlank);
}
The former can basically get inlined 100%. The compiler knows the exact address of the CPU object, because there's only one. The latter has to go through a pointer to get the address. Even though it's always a constant under actual emulation, the code basically has to account for the fact that you could change the pointer at any time. Even if you tried binding it as a reference, eg CPU(GameBoyAdvance&), the performance penalty remains.
Long ago, I wrote some #define wrappers so I could say "cpu().raiseInterrupt", and depending on compilation flags, it would use CPU cpu; or CPU* cpu; and the results were dramatic: at least a 15% loss of performance just by using the pointer version.
I'd really like the benefits of the latter design, but without the added red tape and performance penalties. But I can't think of any way to pull it off. I really can't afford the performance penalties, as I use 100% of top-end CPUs to try to emulate every hardware nuance possible already. Am I doing the right thing, or is there a better way?
I'm on my phone, so no code examples (sorry). If you want one, reply and I'll write one when I get to a computer!
// Don't throw away that simple old C++98 so fast.
class GameBoyAdvance {
private:
CPU cpu;
PPU ppu;
public:
GameBoyAdvance()
: cpu(ppu), ppu(cpu) // CPU has ref to PPU and vice versa.
{
}
void PPU::scanline()
{
cpu.raiseInterrupt(Interrupt::VerticalBlank);
}
You know your software better than anyone and you clearly know enough about the design tradeoffs involved. Just try to contain your solution to as few classes as possible.
The one good thing about the new/delete approach is that it keeps the master object small, since it's just a farm of pointers. No matter how you define a C64 instance, most of the storage comes from the heap.
I once ran into an issue where declaring a class on the stack was actually crashing the program (running in a small-ish embedded system). The quick and dirty fix was to new/delete the entire object. But when that is out in the open, you expose potential leaks; you need a smart pointer to manage that. Making some of the contents dynamic (so that the class is effectively a smart pointer) is another option.
By way of explanation, I'll focus on just the issue of manual memory management. Simplifying a bit, consider this part of the C64 class's implementation:
The contract in this code is that a C64 owns the chips, the chips are born when the C64 is instantiated, and when the C64 dies, the chips all die along with it. There are two approaches for making this contract explicit, one is to simply not use pointers and references at all: But this does mean we can't use polymorphism within the C64 class, we don't have nullability, and we can't replace the instances. The code doesn't leverage any of these, so that may be an appropriate choice. However, if we need any of those things, we can instead use the appropriate smart pointer: In either case, C64's destructor is no longer necessary. The other classes still take raw pointers (e.g., `Cpu*`) because they do not own the objects they receive and do not dictate lifetimes.It's worth mentioning that many people would use `std::shared_ptr` here instead, but I think that's abuse that leads you towards circular references (memory leaks): the Cpu doesn't own its Memory, they just have their lifetimes managed exterior to them. This would actually come up with the existing design (if shared ownership were used), since the object dependency graph (which is perhaps another issue) has several circular dependencies.