XML. (was: Re: [ODE] outputting objects)

[Nate W]

On Tue, 4 Feb 2003, Anselm Hook wrote:

> I'd still argue that the point is still not the xml itself - it is that
> you need some tool to map between *any* notation and C objects.  

YES.  That, in my experience, is always the hardest part.  The "easy" way
out is to specify the order in which values must appear, then you can
basically use sscanf() to pull values out, but that makes things fragile
so I'm not fond of it.

Juice uses a system that's clever, and easy to use at the application
level, but loading files is abysmally slow.  I'll be packaging the XML
serialization code stuff separately and GPLing it, probably this weekend,
if anyone wants to take a look at it. 

I like your reflection approach, that's pretty cool, and probably faster
than the approach I used.  One thing I was aiming for is to have
serialization and deserialization handled by the same object methods, for
example:

void Joint::vSerialize (Stream &Stream) 
{
	Component::vSerialize (Stream);

	Serialize (Stream, (int*) &m_pBody1,        L"Body1");
	Serialize (Stream, (int*) &m_pBody2,        L"Body2");

	Serialize (Stream, &m_rGain,                L"Gain");
	Serialize (Stream, &m_rMaxForce,            L"MaxForce");

	Serialize (Stream, &m_rLoStop,              L"LoStopValue");
	Serialize (Stream, &m_rHiStop,              L"HiStopValue");
	Serialize (Stream, &m_fLoStop,              L"LoStopFlag");
	Serialize (Stream, &m_fHiStop,              L"HiStopFlag");
}

The "Stream" object has a flag to indicate whether it's reading or
writing.  Writing the file is pretty straightforward, each line just emits
an XML tag.  Reading the file is slow since each joint-related XML tag
means passing through this function and comparing the current XML tag to
the tag for each data member.  It makes for tidy code though, at least
from this view.  The guts of Serialize are a little complex, and the
vSerialize methods of my std::list-derived classes are not pretty.

More later, though... I got a to-do list a mile long...

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com