My whole architecture is based on messages, events or signals (I'm still not sure what the difference is between those three terms; they seem to be used interchangably). From a theoretical perspective I feel it makes the architecture very clean and easy to maintain; components can be plugged in and out of the system, and modifications to a module can be made without affecting any of the others. The problem is that with signals being so fundamental to the system I need an implementation that I'm extremely happy with for me to have trust in the architecture, which unfortunately is not yet the case.
I've looked at Boost::signals which seems powerful enough, but the operational costs appear to be too great for something so fundamental (I may need to do proper tests on this though; I've only briefly looked at Boost).
I've tested the sigslot library which seems more lightweight than the Boost version, although it doesn't quite offer the features that I'd like in all cases. My main concern with sigslot is that it needs to allocate memory for every connection made between a signal and a slot (so slots can automatically disconnect from signals on destruction), which I get a bad feeling about. This might just be my old C programming style speaking, but I generally get very cautious any time I need to use malloc or new; there's always the potential for a memory leak or performance slow downs once you play with memory. I usually prefer to allocate memory in a big block and dish it out when required.
My main concern is I don't know exactly why I've finding this such a problem. I'm pretty sure it's at least partly because I haven't fully sketched out the details of how these signals will interact with every part of the system; I don't think I can do that until I get a clearer idea of what problems I need to solve. I hope it isn't just a case of "Not Invented Here" syndrome, although I expect there's a small part of that; I'm uneasy using code I don't fully understand the performance characteristics for for something so fundamental.
I've tried searching around for more information, but that seems to have made my feelings worse. For a start I find searching on these forums for nearly anything I wish to know tends to bring up my own journal in the first five hits, usually with a quote like "I need to research more about X". That's annoying, and more so when searching on something esoteric so the whole first search page is full of those journal entries.
However when I do look at advice not written by me it just hammers home how little I know about what I'm doing. There seems to be a thousand little details I need to consider in order to make a decent game architecture and my programming skills are probably nowhere near up to scratch. The paradox is the only way I can improve those skills is by writing the prototype of the engine, but I feel I can't write that prototype without improving my skills. This is one case where ignorance would have been bliss; I'd actually have a better chance if I didn't know my coding was so crap.
If I were only interested in making games, then the sensible thing would be to just use someone else's engine, or better yet learn a higher level language so I don't have to delve into all this lower level nonsense. However in a few months time I'd like to experiment with some additional algorithmic features that I rarely see in third party game engines (or in fact games in general); integrating SVG deeper into the engine, interactive music with the gameplay, generating game levels, and so on. Some of those things can only be done if I have an understanding of the guts of the engine.
So the question is: how can I overcome this problem? I've partly I've written this journal entry in an attempt to brainstorm through the problem myself as well as share it with the community. I'm thinking now that part of the problem is that not all signal systems within my engine are the same; the types of signals the input system needs to throw are different from kernel task update signals or that which a collision detection system might throw. It might be worth not considering having a signal base class at all, and just go with specialised implementations tailor made for each application. Maybe once I've written them all I can see if there's a common core to all (or some) of them, and combine them into a single class.