I've designed a simple interface for classes to add XML access.



Just inherit from XmlObject, and then implement ToXml and FromXml. I thought initially to make the function pure virtual, but there's no reason a class shouldn't just overload the load function, if they don't have any interest in saving. If the save function does get called, it'll just fall down to the base class and return false. No harm done.

I also thought about making the constructor protected, to prevent anyone from allocating XmlObject instead of a derived class. Other than preventing someone from compiling something I can't see any use for, is there any real reason to do it?

A third thought I had was to have a third function, which is a different version of ToXml that returned a TiXmlElement. This would eliminate the need for the calling function to create a TiXmlElement in their scope. Also, two of the utility functions I wrote were overloaded operators for + and +=. If I just return the element, I can do stuff like this:

TiXmlElement xmlSave = class1.ToXml() + class2.ToXml(); 

The problem I have with that, is I really prefer having the option to return a success flag. Most of the code I write for work is in C, so throwing exceptions isn't my first thought when I'm coding on my own. Obviously that's something I need to work past, because exceptions seem to the right way to do handle these error conditions.

I modified my test classes to use this interface, and uploaded the new files. I also remembered to upload the XML file I'm using to test with, as I forgot that last time.

text.xml

Next time I'll get to the reason I wanted this uniform interface, other than my craving for uniformity.