-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Robert,
Robert Osfield wrote:
>
> I've never used TinyXML/TinyXML++. I'm certainly open to adopting a
> more capable XML parser than the one I've written so far. I'd rather
> not add yet another external dependency for core OSG features, which
> is why I opted to roll my own XML parser for Present3D (and the .p3d
> plugin) rather using libxml2.
The dependency is tiny, the code is pretty easy to use:
ticpp::Element *fog_e = root->FirstChildElement("fog");
std::string fogname = fog_e->GetAttribute("name");
// get attributes
// colour of the fog
float r = 0.2, g = 0.2, b = 0.2, a = 1.0;
try
{
ticpp::Element *color = fog_e->FirstChildElement("color");
color->GetAttribute("r", &r);
color->GetAttribute("g", &g);
color->GetAttribute("b", &b);
color->GetAttribute("a", &a);
}
catch (ticpp::Exception &e)
{ /* not present */}
fmgr->setColor(osg::Vec4(r, g, b, a));
etc.
>
> Merging TinyXML/TInyXML++ into the core OSG might be a reasonable
> thing to do, but only if it's easier to understand and maintain than
> rolling this code ourselves. My experience with a writing quick XML
> parser suggests that this tasks isn't a big one.
I definitely prefer using something like TinyXML or SAX to writing my
own parser - parsing trivial files is easy, once you get into obscure
things where encodings, schemas and what not that needs to be handled at
least to the degree that the parser doesn't choke on it, it is not fun
any more.
Regarding merging TinyXML into OSG - please, don't! It is very easy to
do and a lot of projects do so. This causes crazy problems once you try
to combine two libraries that use their own copies of TinyXML, neither
has put it into a namespace and the two copies are not identical. I have
hit this problem before with ReplicantBody, I believe, and it was a
non-trivial issue to deal with.
> In the context of port our Collada plugin across to use our own .dae
> parsing code I think that the low level parsing code itself is an
> order of magnitude less work that the actual work on the dae side.
> Tweaking the XML parser classes to support that type of files that
> we'll get with dae may well be advantageous i.e. we can make our
> parser Matrix/Vec/OSG object aware.
That you can do even with a 3rdparty parser - e.g. the code above is
parsing the data into OSG data structures.
I think that the right way to go is not to avoid a 3rdparty dependency
when one is needed at all costs by duplication of work. An XML parser is
something so common that I do not see a good reason for creating a yet
another incomplete implementation. I understand the pain with
dependencies well, but this will only add an extra piece to maintain.
Pick a well known, supported and working implementation and stick with it.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFKAca0n11XseNj94gRApB9AJ99pbCGUYy7+Bs5xDuxAlI+hdyBiwCggSI/
L0VQS7p9jsXxuck666aONI8=
=JcTa
-----END PGP SIGNATURE-----
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
