XCG is a command line utility for transforming the structure of an XML instance into some kind of structure. It was created to help me generate wrappers for several dozen different XML formats that I was working with. As a result of the need, the first version generated c++ code wrappers around libxml2, which after a lot of research appeared to be the best solution for my XML reading and writing needs.

Now, it is much more powerful than that what I just described. Instead of just generating c++ wrapper code, it now generates based on the contents of its configuration, which is contained within XML. In fact, it uses itself to generate the code to read the XML configuration file (well, not directly, but its the same end result). It could be self hosting simply by embedding a copy of the default XML configuration in the executable; I chose to keep it external to make it easier for others to modify the default code generation.

I suppose I should explain why I didn't use a DTD or schema as the basis of the generation. Problem is, I don't really have what I consider solid reasons. For most of the XML data I was involved with, there either wasn't a DTD or schema, or if there was, it was out of date. I suppose I could have made the creation and/or update of the DTD's or schema a requirement, but in the end, I found myself creating a lot of last minute simple XML instances with all kinds of short little formats for things that would never be used again (look at example3 for a real world example). Yes, I could have used XSL to do some/most of these translations and such. However, in the end, I think what made me choose this method was a library named TinyXML that has a pretty faithful following because it is so easy to use (alas, it has a few issues that make it unusable for me). I also wanted something that was as easy to use, but which would be much more flexible. This is where I ended up, and I am actually very happy with the result! If one is familiar with stl, then the default code generation is pretty straight forward to use; Because all elements are wrapped in objects, and those objects don't allow direct acess to any data, it actually is highly maintainable as well. As always, there are a few things I still want from it, but its a great start.

As a result of using a configuration file (called a "template"), there are very few limitations on what XCG can generate. So far, the limitations I have encounterd are more annoyances than limitations; Issues I got around by making significant modifications to my template - but which a few extra featuures will eventually make much easier to deal with.

The following is a list of the major features (or functionality) provided by XCG in its current form: