C ++和SOAP
我有一个C ++应用程序，需要连接到一个JAVA Web应用程序，有没有任何好的，开源的SOAP包，或者是否更容易自己滚动？
我会投票支持darkhelmet，因为gSoap也是我的推荐。 我们主要是一个Java商店，但有一些C ++位，gSoap一直是我们首选的SOAP集成方式。 它确实比典型的Java堆栈更多，但看起来很稳固。
一个快速的谷歌出现了这个工具包。 虽然我从未使用它，但它似乎非常受欢迎且非常坚固。 不完全是一个包，并没有真正滚动自己，而是在中间。
我们使用gSOAP而不是Axis来避免仅仅为了构建C ++项目而依赖于JRE和Axis。 它运行正常，这很好，因为gSOAP代码非常糟糕，并且修复它中的任何错误都非常令人生畏。
关于gSOAP链接的警告：您永远不能在单个链接对象（可执行文件，DLL，共享对象）中使用多个WSDL。 这是因为某些生成的WSDL特定函数具有通用名称（例如soap_getfault（））。
更糟糕的是，使用Unix ELF链接时，这些名称将导致共享对象之间的交叉链接，因此，对于BarService，soap_getfault（）可能会处理FooService错误，如果错误详细信息结构不同，则会损坏内存。
解决方法是确保没有任何与gSOAP相关的内容暴露在它们所链接的SO之外。 这可以通过在链接gSOAP库本身和链接代码时给gcc这些定义来解决：
#define SOAP_FMAC2 __attribute__ ((visibility ("hidden"))) #define SOAP_FMAC4 __attribute__ ((visibility ("hidden"))) #define SOAP_FMAC6 __attribute__ ((visibility ("hidden"))) #define SOAP_NMAC __attribute__ ((visibility ("hidden"))) 我通过将它们放入头文件并强制gcc在-include fixsoaplink.h之前包含它来解决它。
如果您可以采取措施，更好的方法是将默认ELF可见性更改为隐藏，并仅导出您想要的符号（如VC中的dllimport / dllexport）。
看看Apache的Axis项目。 它在C ++（和Java）上得到了很好的支持，如果您有幸从目标服务的良好WSDL开始，那么您将无家可归。
当我看到gSOAP生成的代码时，我心脏病发作了。
事实上，用户需要为每个对象进行所有内存管理，这让我大吃一惊。 所以，我坐下来做了一些长期可能是愚蠢的事，但在短期内相当令人满意……
我编写了一个程序，用我自己的CPP类包装gSOAP代码，使界面看起来更像我想要的样子。
我在每个服务方法中使用Scoped Guards来保留内存，因为我正在处理各种不同的类型，所以我使用std::list来完成它。 我有一些函数可以生成我需要的每个对象类型，并且它们将实际内存放入我的list 。 它有一些问题 – 主要是配置更改。 我现在正在生成数千个课程，与几十个Web服务交谈。
我不确定我是否会向其他人推荐相同的路径…我应该咬紧牙关并开始尝试为gSOAP做出贡献，而不是维护我自己的工具，这取决于gSOAP的输出……
这是gSOAP的另一个问题，我们刚刚发现了一个困难的方法：它使用select（）进行所有轮询，所以一旦打开1024个文件描述符（Windows上有64个？），它就会丢弃堆栈。 这导致无法发送消息的虚假错误，以及完成应用程序的崩溃。
除非你准备修补gSOAP本身，否则解决方法是编写你自己的网络代码并用soap-> fconnect， – > fsend， – > frecv等挂钩。