Well, gave up on the swinging about on the extendable arm project. Just didn't seem to be panning out.

The above project is back and alive and well. It's been rewritten from scratch and is much improved. Everything is now properly data driven and the general structure is a lot more tidy.

My extensible configuration script stuff is making it far easier to write heavily data driven games. I'm very pleased with it. I keep meaning to get round to writing up some proper documentation and putting up a little website to see if anyone else has any use for it, but that's one of those dull jobs that I never seem to get round to.

I should also probably spend an hour or so trying to break it, since I'm only using it in the ways I've intended. I had a tricky bug that kept coming up the other day where I'd done something like:

xcs::node N=Config["stuff"];

instead of

xcs::node &N=Config["stuff"];

and everything kept crashing. Took me ages to spot the mistake. I've since made the copy constructor and assignment operators private to the node class to catch the error at compile time, but I'd guess there is probably a plethora of other gotchas that I haven't really thought about.

One feature that has worked out very well so far is the use of stringstreams to do the conversions internally. You can do stuff like:

int I=Config["data"]["values"]["my_value"].as();

but since the as() method uses a stringstream, this can be extended to deal with user-defined types just by including a normal stream extractor the same as you would to read your data from cin and other standard istreams.

I know that there are no real advantages over something like XML, but the usage syntax for XCS is very concise when you know the structure of your data in advance, and I likes it.