I managed to get Boost installed in Xcode on my MacBook Pro. Things got complicated due to my inexperience of installing libraries on a Unix flavoured OS. I've had some experience with shell consoles at uni but I've never had to act as an administrator before.
There was some difficult in getting the complier to read the Boost header files as apparently the standard install directory of /usr/local/lib isn't included by default. For some reason I couldn't figure out how to include directories into the standard search paths in the compiler. I had to kludge things a bit by creating a symbolic link in one of the framework directories.
However after doing all of this I started getting second thoughts about using Boost as the basis of my signals. Admittedly I had an inkling of these when I read through the slightly confusing documentation which outlines how boost::signal contains every feature but the kitchen sink; it seems like overkill for my signalling needs and given how integral it will be it sounds a bit bloated.
I had further doubts when I cracked open the source filed to try and understand how to code something like a signal/slot system. Since the Boost code is designed to be extremely cross platform it's full of heaps of preprocessor commands and split over at least a dozen files. Given I'm also not that comfortable with templates and signal code apparently needs heaps of this I couldn't make head nor tail of it.
So I've decided to try something a bit simpler as the basis of my signal code. I've downloaded a copy of sigslot and it seems to be perfect for what I need; it's got just the right amount of functionality that I would want to implement if I were to attempt to write the code myself. Plus the code itself looks much more understandable (although the author apparently doesn't like to use comments. What is it with these library writers and their aversion to comments?)
The only question I have to ask myself is whether I still want to convert the code to using my own brand of interface by wrapping it a code layer of my own. On the plus side it may be useful for such a critical part of code to use the same type of naming as my own, and I can add comments and debug messages in without disturbing the original code. But on the minus side it looks to be a pain to wrap something so heavily templated in another layer.
My gut feeling is to leave it for this first version of the library; I can try and get the basic architecture down right and then figure out the naming details with a rewrite and polishing in the second version. I also now think I'd feel a bit guilty if I tried to hide someone else's code with my own interface if it's essentially exactly the same, even if I end up the only person ever to see it.
In other news, crumpets with honey are awesome.
