问题标签 [rapidxml]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - rapidxml:如何遍历节点?省略最后一个兄弟姐妹
使用 rapidxml 我想遍历一组节点,并使用我发现的最佳方法来执行此操作(来自可靠的 stackoverflow,文档似乎没有迭代示例):
不幸的是,在我的 OSX 10.6 上,这遗漏了最后一个兄弟节点——我猜是因为在循环的最后一次迭代中, next_sibling 被调用了两次。如果我写的话,我可以在循环之后到达最后一个节点:
...但这很狡猾,程序在那时退出。
第一个问题:这可能是我的设置(OSX 10.6)的一个独特缺陷还是我编码错误?
第二个问题:有没有人有他们认为使用 rapidxml 遍历未知数量的 XML 节点的正确方法的示例?
多谢你们
皮特
c++ - 使用 RapidXML/C++ 类指针副作用解析中的递归问题
我想分享一下我最近在尝试使用 RapidXML 在 C++ 中进行 XML 解析时偶然发现的这个奇怪但有趣的情况。
我想编写一个递归函数来搜索并返回给定节点的子节点中的特定节点。我的第一次尝试是:
它碰巧只与第一个孩子一起正常工作,但是如果您搜索嵌套在 XML 文件中更深的节点,则会找到该节点(我看到了 cout 的),但是在 return 语句之后,for 循环似乎运行了一个(或一些)更多时间(可能是因为递归的调用堆栈),然后退出并且指针丢失。
所以我尝试用一个临时变量来修复它,这样:
但是什么都没变。。
不幸的是,RapidXML 中的节点是类指针,所以在这种情况下,副作用会阻止我提取正确的结果。
任何人都发现了这种情况,或者以另一种方式解决了这个问题?
c++ - 带有 url 属性的 rapidxml 解析错误
在解析像这样的 xml 文件时,我遇到了 rapidxml 的奇怪错误
它抛出“预期>”。我使用如下代码来解析数据
IMG 抹布中的“/”符号似乎不是问题所在。这是一个 rapidxml 错误还是我做错了什么?
c++ - RapidXML 抛出 parse_error 异常
当我尝试使用 RapidXML 框架解析一个简单的 .xml 文件时,它会抛出一个 parse_error,原因如下:“expected <”。现在这实际上是我第一次编写 XML 代码,所以这可能是一个愚蠢的语法错误,在这种情况下,请耐心等待 :) 这是我的xmlParser.h:
这就是它的调用和使用方式:
login_gui.xml:
c++ - RapidXML 从文件中读取 - 这里有什么问题?
这两种读取输入文件的方法有什么区别?
1)使用'ifstream.get()'
和
2)使用vector<char>
with ifstreambuf_iterator<char>
(我不太了解!)
(除了使用漂亮的向量方法的明显答案)
输入文件是 XML,如下所示,立即解析为 rapidxml 文档。(在别处初始化,参见示例主函数。)
首先,让我向您展示两种编写'load_config'函数的方法,一种使用ifstream.get()
,一种使用vector<char>
方法 1ifstream.get()
提供了工作代码,以及一个安全的 rapidXML 文档对象:
方法 2 导致另一个库破坏了 rapidXML 文档 - 具体来说,调用 curl_global_init(CURL_GLOBAL_SSL) [见下面的主要代码] - 但我还没有将其归咎于 curl_global_init。
主要代码:
我非常确定这一切都是在一个线程中执行的,但也许有一些事情超出了我的理解。
我也担心我只是解决了一个症状,而不是一个原因......通过简单地改变我的文件加载功能。在这里向社区寻求帮助!
问题:为什么从向量移到字符数组可以解决这个问题?
提示:我知道 rapidXML 使用了一些巧妙的内存管理,实际上直接访问输入字符串。
提示:上面的 main 函数创建了一个动态的(新的)xml_document。这不在原始代码中,而是调试更改的工件。原始(失败)代码声明了它并且没有动态分配它,但发生了相同的问题。
另一个全面披露的提示(尽管我不明白它为什么重要) - 在这个乱七八糟的代码中还有另一个向量实例,它由 rapidxml::xml_document 对象中的数据填充。
c++ - 正确选择文件流对象
应用程序使用 RapidXML 来编辑 XML 文件。编辑不是自动化的,偶尔会发生:XML 内容显示在 GUI 中,用户执行一些更改 XML 的操作。每个更改都必须立即保存到磁盘。
加载 RapidXML 文档对象需要将文件内容复制到字符串中。文档中的每次更改都会将文档对象的内容复制回文件中。
在此示例中,文件用于输入和输出。在这种情况下,是否应将单个std::fstream
对象用于所有输入/输出操作?它将在应用程序启动时打开一次,用于输入/输出,并在应用程序结束时关闭。
std::ifstream
std::ofstream
或者,是否应该在需要执行文件输入/输出时使用和的本地(临时)实例?例如std::ifstream
,在开始时用于读取文件(打开、读取、关闭);类似地,std::ofstream
当必须将 DOM 导出到文件(打开、写入、关闭)时使用实例。
我不关心这里的性能(由于应用程序的性质),但对在这种情况下正确选择文件流对象感到好奇。
c++ - 如何迭代xml文件并将其存储在地图中
如何使用 rapidXml 迭代文件并将其存储在地图中......就像使用文件的内容创建字典一样。我已经尝试过了,但我只能获得第一级键值对,而不是内部级别。
c++ - 错误处理:区分“致命”错误和“意外输入”错误
我一直在开发一个读取 XML 文件的程序,如果 ifstream 无法打开文件,它将抛出 std::ifstream::failure。每当设置 std::ifstream::failbit 或设置 std::ifstream::badbit 时都会引发此异常,并且它们(至少在我看来)是需要处理异常的错误类型。
打开文件后,我使用 RapidXML 创建 DOM 对象,如果失败,它的 parse 函数将抛出 rapidxml::parse_error。在这种情况下,错误并不是真正致命的——它只是错误的输入。无论如何,我认为rapidxml在解析xml文件失败的时候抛出异常还是公平的,但即使我不这么认为,也无所谓,因为我没有太多的选择. 我可以在 RapidXML 中关闭异常,但是我仍然必须手动处理这些异常情况,而且通过异常机制处理它们要容易得多。然而,这绝对是一个阴暗的领域。rapidxml::parse 抛出异常的理由并不像 ifstream 那样明确。
最后一种情况是当我解析 DOM 并遇到意外或未预料到的节点时。显然,尽管有意外的输入,程序仍可以继续执行,但我不希望它这样做。我可以想象在这里抛出一个异常,但我不确定这是否有意义。
所以,我想请教一个小建议:异常处理的一些最佳实践是什么?我尝试通过在构造函数中执行所有这些来在解析文件的类中使用 RAII 习惯用法。我使用 boost::shared_ptr 来实例化文件解析类,因此如果构造函数抛出,boost::shared_ptr 将在删除文件解析类后重新抛出 std::bad_alloc。
当 XML 文件不符合此类的预期时,我可以提出一个论据,我认为在出现意外输入时抛出异常是有意义的,但我真的只是想确保我的思维过程是正确的。
c++ - 如何使用 RapidXML 生成 xml 样式表声明?
我知道如何生成常规的 xml 标头 (),但我看不到如何专门生成 xml-stylesheet 声明。以前有人做过吗?谷歌搜索这个问题没有任何相关性。
c++ - 在 Windows CE 6.0/Windows Mobile/Windows Embedded Compact 下使用 RapidXml 的奇怪异常
尝试在使用 Visual Studio 2005 编译的 Windows CE 6.0 下运行 RapidXml 1.13 时遇到一个非常奇怪的问题。我有一个非常小的程序无法运行:
它编译得很好,有 0 个错误和 0 个警告(在 W3 时)。但是,当我运行或调试程序时,我得到一个访问冲突异常:
RapidXml_Test.exe 中 0x000110d4 处的第一次机会异常:0xC0000005:访问冲突写入位置 0x0001fb48。
然后调试器将这一行(rapidxml.hpp 中的 1366)作为罪魁祸首(左大括号)指向:
如果有人有任何线索可能是什么问题,我将不胜感激。我的构建和运行时环境中有更复杂的代码工作,所以我不怀疑那里有任何东西。我也相当有信心这不是一个项目设置。在这一点上,我假设 RapidXml 对模板的使用以某种方式混淆了 Windows CE VC++ 编译器。我不知道还能是什么。
提前致谢!