I also discovered I hadn't yet installed Boost for Code::Blocks on my PC. After cursing a bit to get Boost.Jam to work properly it's now compiling as I type this up. Hopefully it'll compile more or less successfully.
The other little snag is the next item on my checklist is the logging system, and that requires me to do some cross-platform friendly file I/O. This reminded me that I needed to set everything up nicely for cross-platform work, so I've been figuring out a system to get that working too.
Since this is my first cross-platform project I wasn't sure on the best way to organise my code. My current plan is to try and make everything as cross-platform friendly as possible, use preprocessor commands for anything small that's platform dependent, and rely on seperate files for larger elements that vary across systems. For now I've just got a header file called dgl_build.hpp that defines build and OS flags that get linked in with the compiler, i.e:
#define DGL_DEBUG_BUILD 1#define DGL_PLATFORM_WIN32 1
Then the compiler can just link to whichever is appropriate.
I'm still not sure on what the best way is to deal with the differing file systems. I'm assuming that I can std::ofstream without any trouble, but I don't know about where I should be saving these log files. Previously I've been saving them within the application directory itself, but that isn't particularly good form. I'm not sure if there's a nice way to find where an operating system expects files like that to go.
Currently I'm planning on experimenting with Boost.filesystem (once it compiles), and see if I can get some insight. I'll probably end up hard coding in where the user directories are for various platforms - although now I think of it I can't remember if there were differences in various forms of Windows.
Additional:
How flippin' long does it take to install Boost??! Plus the annoying thing is I've installed it into a generic directory when really I'd like to put it in with the Code::Blocks libs and include files so I'll have to install it again. [headshake]
I know you weren't really talking about signals/slots in this entry, but if I commented in the other entry I feared you wouldn't see it. The type casting and variable argument stuff is looking pretty vile. I came from C --> C++ so I think I know where you're coming from, but I'm sure there's a better (safer) way. Actually I've been working (fumbling) with something similar and I was hoping one of the more experience developers here would chime in and say, 'here is the One True Way to solve this problem!' Alas.
One way of avoiding the variable argument hell is to just use a single argument and make it a generic struct, i.e.
Any time you want to pass new types of data, subclass the struct. One of the benefits of taking this approach is that you can stuff as much data in there as you want, and if you make a change to the data passed through a given struct you don't have to change anything except for the struct.
Just a thought. Hopefully someone more experienced will dispense their wisdom on the matter. [smile]
Good luck!