Cross platform log files

Published May 04, 2007
Advertisement
Yet another double entry from me today. My last addition to the previous entry stated that I'd finished with the signal and event system, and as such I'd crossed it off my list of things to do. However I'm uncomfortable with the adhoc testing I've given the system so far given how critical it will be. I'd feel happier if I built a unit test. This requires me to write a unit testing system which I'm currently planning and writing.

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]
0 likes 5 comments

Comments

jjd
Hey Dave,

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.


struct MyData
{
};



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!


May 04, 2007 08:44 AM
Ravuya
I have some operating-system abstraction code kicking around that handles getting the users' Application Support directory (in OS X) or their My Documents\My Games directory (in Windows).

It also offers CPUID and dialogue boxes, as well as some other services (and eventually service discovery with Zeroconf).
May 04, 2007 10:21 AM
Trapper Zoid
Quote:Original post by Ravuya
I have some operating-system abstraction code kicking around that handles getting the users' Application Support directory (in OS X) or their My Documents\My Games directory (in Windows).

It also offers CPUID and dialogue boxes, as well as some other services (and eventually service discovery with Zeroconf).

Is that part of your Propane Injector library? I'm looking through PropaneFS as an example. I didn't know you also had dialogue boxes in there as well; I'll have to hunt down the associated code. Thanks!
May 04, 2007 05:32 PM
Trapper Zoid
The casting is particularly vile, but I don't know a better way around it. If I could use an empty base class in this case I would, but (I'm fairly sure) it wouldn't work in this case.

The problem I need to solve is how to store a bunch of different classes in the same array. In this case the classes are all FastDelegates, named after the number of variables they can take and with template parameters (FastDelegate0<>, FastDelegate1<int> and so on). They are exactly the same size in memory, so from a hardware perspective it's fine to store them in the same array, but strongly typed programming languages throw a hissy fit if you try to do that.

My kludge is to define a useless memory block that's the right size in the array and to cast between the right FastDelegate when it needs to be accessed. It seems to work, but it's ugly. I might post a question on the programming forum to see if someone has a better way to solve this problem.
May 04, 2007 05:49 PM
Ravuya
I don't think the Propane::OS stuff (CPUID, dialogue boxes) is available in the build that's up on the website; I've got it in SVN and can dump it if you ask.
May 06, 2007 11:54 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement