XSD 生成的解析器中的 gSOAP 替代方案答案

【问题标题】：gSOAP alternative in XSD genereated parserXSD 生成的解析器中的 gSOAP 替代方案
【发布时间】：2012-12-03 20:09:49
【问题描述】：

我正在使用 gSOAP 从我自己准备的 XSD Schema 生成 XML 解析代码。它与 Web 服务无关。 XML 数据从本地文件或内存缓冲区中读取（通过提供适当的 istream 到 soap）。

起初看起来很简单。但现在随着我越来越多地使用它，我开始发现一些问题。

例如，名称是在全局命名空间中引入的。可以强制使用命名空间，但随后构建变得更加困难（由于需要生成额外的代码来处理错误），只能使用一个命名空间，并且由于使用宏，它也可能导致其他问题。

一旦每个二进制构建单元有多个模式（.exe、.dll、...），您就确实需要这些命名空间！

所以我开始考虑一些替代方案。特别是我不需要那些网络服务人员。仅基于 XSD 解析 XML 的自动代码生成。

有没有这样的替代品（对于原生 C++）？它们是什么？

【问题讨论】：

标签： c++ xml xsd gsoap

【解决方案1】：

以下是有关 XML 数据绑定的资源列表： http://www.rpbourret.com/xml/XMLDataBinding.htm

【讨论】：

【解决方案2】：

gSOAP 的 wsdl2h 的 XSD 转换不会产生 C++ 名称空间，而是将 XSD 名称空间映射到一个非常易于使用的前缀名称约定 (ns__name)，并且避免了 C（和 C++）中的名称冲突。任何绑定工具都必须强制执行这种映射规则。你为什么说“一旦每个二进制构建单元有多个模式，你就需要这些命名空间”？您可以简单地在所有 XSD 上一起运行 wsdl2h。

【讨论】：

花了将近一年的时间才得到一些答案！ ;)
将所有 XSD 编译为一个既不实用也不利于设计。考虑将来自不同库的多个松散相关的 XSD 合并为一个，因为所有这些库最终都将位于同一个二进制模块中。你觉得好看吗？
它是一个代码生成器，所以库设计模块化的旧规则不适用于恕我直言。您可以为项目选择任何 XSD 子集并生成专用库。与 C++ 模板库（内部代码生成）相同的概念：有很多模板可供使用，但您选择使用的模板是实例化的。只需确保通过 typemap.dat 绑定分配 XML 命名空间前缀。