RapidXML API 可以增加缓冲区吗？
查看文档RapidXml 中的 XmlDocument::parse(Ch*)，我想知道字符缓冲区是否为“非 const”。我不确定当缓冲区需要通过解析器的任何此类修改来增长时，这通常会如何工作。图书馆会做种植吗？如果我要求它解析，它应该解析对吗？否则它应该被称为 ParseAndPossibleModifyButLetMeKnowIfYouHadToRegrowTheBufferInWhichCaseHeyCheckThisFlagAndCopyThisPointer 或类似的东西。
我错过了什么吗？我想了解这个库，因为我想要一些易于使用的东西来从 C++ 动态打开和附加/编辑 xml 文件，但如果有更简单/更好的替代方案请毫不犹豫地提出这样的建议作为答案！ ！
Seeing the documentation of XmlDocument::parse(Ch*) in RapidXml, i'm left wondering about the character buffer being 'non const'. I'm not sure how this is going to work in general when the buffer needs to grow by any such modifications of the parser. Will the library do the growing? if i am asking it to parse, it should just parse right? otherwise it ought to be called ParseAndPossibleModifyButLetMeKnowIfYouHadToRegrowTheBufferInWhichCaseHeyCheckThisFlagAndCopyThisPointer or something like that.
Am i missing something? I want to understand this library because i want something that is simple to use to open and append / edit xml files on the fly from C++, but if there are simpler / better alternatives do not hesitate to make such suggestions as answers!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
RapidXML 尽力成为一个就地解析器。当它不能时，它将分配内存（链接到
xml_document的生命周期），但仅在必要时分配。由于 XML 读取而导致字符串实际增长的情况相当罕见。它将修改字符串的内容（除非您设置非修改标志），并且其对象将保留对该字符串的引用。因此，您需要确保缓冲区能够存活足够长的时间。但除此之外，没有什么可担心的。
RapidXML tries its best to be an in-place parser. When it can't, it will allocate memory (linked to the lifetime of the
xml_document<>), but only when necessary. It's fairly rare for a string to have to actually grow due to XML reading.It will modify the contents of the string (unless you set the non-modifying flag), and its objects will keep references to that string around. So you need to make sure that the buffer survives for long enough. But other than that, there's not much to worry about.
Rapidxml 永远不需要增加缓冲区。幸运的是，UTF8 编码的 XML 始终在字符串周围有足够的空间来插入终止空字符并就地扩展内置字符实体。
因此，唯一的修改将是缓冲区的内容，而不是其大小。
Rapidxml never needs to grow the buffer. By a lucky coincidence UTF8-encoded XML always has enough space around strings to insert terminating null characters and expand built-in character entities in place.
So the only modification made will be to the contents of the buffer, never its size.