我们写的一个小巧的XML解析类，感兴趣的可以用用。

superdai

支持。

lights

作者对我认为代码不小巧提出了疑问，在这里说下自己的意见。
1.没有使用std::string或其他字符串，std::vector你都用了实在没有任何理由拒绝std::string
这一改变就可以删去xml属性的结构，直接用一个std::map<std::string,std::string>在xmlnode中表示属性，代码减少，检索也方便。
2.XmlDocument完全是一个无聊的类。只在xmlnode中加一个loadfromfile的函数即可，close？这个函数完全没有存在的意义。这样修改的好处也是浅而易见的，一个xml结构可由多个文件搭建而成。
3.解析的代码非常有问题，我死活想不通为什么需要回滚这种操作，一个循环的GetText函数加一个递归的parse函数足以。这部分的代码具有很大的压缩和提炼空间。

4.其实是不相干的，如果不是非常抵触微软的xmlparser,用他来转换成xmlnode，代码100行左右。缺陷是不能脱离windows平台。

hanma

楼上的，本想跟你私下讨论一下，没想到你会回帖。
1 关于string的问题，主要是比使用char*效率低。差别在一个数量级之间。主要原因是用节点中用string会涉及大量的复制和分配。
2 XMLDocument是为了更清晰的使使用者清楚如何使用这些函数。并且封装了文件读入和解析的功能，如果安排在节点中，概念是不清晰的。节点有节点专门的用途。
3 解析可以压缩和提炼确实是有可能的吧。可能会有更好的方案。
   回滚是为了在出错后，能自动返回到未出错的位置。免的每次都要写同样的设置字符串位置的代码。
4 说实话我对那种面向更广泛应用的代码在游戏这种场合效率是否合适，我心里没谱。

lights

1.相信已经没有人再怀疑std::string的效率了，数量级的差距绝对夸张。
2.XMLDocument的存在也许会令代码清晰一点，这不过是建立在节点作为单纯的数据载体的这种思路的基础上，如果每个节点都可以对应一个文件呢，层面不同的话，优势就不同。
4.微软的xmlparser的效率是不高，但还不是到不能接受的程度，况且xml的读取，在游戏中是即时性要求很低的。

hanma

  在节点中使用串，并且要修改，会导致string分配缓冲区和复制信息。假设XML由几千个串组成，你想效率会如何？数量级的差距不仅不夸张，而且有点保守。
  微软的东西，在运行状态下进行查询的效率也很难说。

lights

std内部的内存管理不会频繁分配，
你可以用数据测试的，memcpy这种操作对电脑来说非常轻量级。

hanma

恩。

6spring

关于用不用string，其实是因为逐字符解析的缘故，搂主的意思是如果用string，需要反复string +=操作，低效。

直接保存缓存中的指针，是少了很多复制操作，但带来了一个毛病——任何修改值的操作，都有可能把Buffer写乱。（不过这个类已经说明了，只是解析）

ddrmsdos

楼主超强！本想自己写一个，现在有现成的，偶要好好研究一下。

hanma

  楼上的过奖了，实在担当不起。