为何明明很简单的函数声明,用wsdl2h.exe生成后变得很复杂

shakaqrj 2016-03-02 09:31:29
步骤这样:
写一个头文件server.h:
int ns__add(int num1, int num2, int *sum);

用soapcpp2.exe生成相关的文件,其中包含一个ns.wsdl

再用wsdl2h -s -o service.h D:\XXX\ns.wsdl(我也不知道这样对不对 依葫芦画瓢)
结果生成出来的service.h变成了这样


int __ns1__add(
_ns2__add* ns2__add, ///< Input parameter
_ns2__addResponse &ns2__addResponse ///< Output parameter
);
class _ns2__add
{ public:
/// Element "num1" of XSD type xs:int.
int num1 1; ///< Required element.
/// Element "num2" of XSD type xs:int.
int num2 1; ///< Required element.
/// A handle to the soap struct context that manages this instance when instantiated by a context or NULL otherwise (automatically set).
struct soap *soap ;
};
class _ns2__addResponse
{ public:
/// Element "sum" of XSD type xs:int.
int* sum 0; ///< Optional element.
/// A handle to the soap struct context that manages this instance when instantiated by a context or NULL otherwise (automatically set).
struct soap *soap ;
};


为何明明很简单的一个函数,却被包装成这样?如果我用这样的头文件soapcpp2.exe 生成出来的文件肯定和之前用server.h的不一样,最后多半调用不成功吧
是不是我生成头文件的方式有误?
...全文
420 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
Pingo520 2017-03-14
  • 打赏
  • 举报
回复
你只有.h文件,没有实现的cpp文件?实现的cpp函数还要在参数列表里加一个soap* t_soap参数,这个参数传入的是连接参数,包括端口。 可以参考这个http://blog.csdn.net/educast/article/details/12653069
weiyajingjing 2017-03-14
  • 打赏
  • 举报
回复
引用 3 楼 oyljerry 的回复:
因为需要序列化等,所以会生成一些结构数据来进行处理
我改了一下.h文件的编码格式,//gsoap ns service encoding: encoded 改为Literal 。就出现这个情况了,客户端写好,调用,提示SOAP-ENV:Server[no subcode],看论坛说是端口不对应,不知道是啥问题
oyljerry 2017-03-14
  • 打赏
  • 举报
回复
因为需要序列化等,所以会生成一些结构数据来进行处理
Pingo520 2017-03-14
  • 打赏
  • 举报
回复
生成规则就是这样,你没必要纠结这些。你要用别人的东西,就要遵循别人的协议。
weiyajingjing 2017-03-14
  • 打赏
  • 举报
回复
其实这个不影响Java客户端的调用,没有别的影响。比较纠结的是为什么编码方式不一样,用wsdl2h生成的.h文件不一样呢? 其实,我感觉也不用wsdl2生成.h文件,直接用自己定义的.h 就行,直接生成c++客户端代码,完成c++客户端。 还有一点就是发布的时候,.h文件中的localhoust要改成局域网IP
weiyajingjing 2017-03-13
  • 打赏
  • 举报
回复
我也这问题,估计是生存的wsdl文件不能用。不知楼主解决没
gSOAP编译工具提供了一个SOAP/XML 关于C/C++ 语言的实现,从而让C/C++语言开发web服务或客户端程序的工作变得轻松了很多。绝大多数的C++web服务工具包提供一组API函数类库来处理特定的SOAP数据结构,这样就使得用户必须改变程序结构来适应相关的类库。与之相反,gSOAP利用编译器技术提供了一组透明化的SOAP API,并将与开发无关的SOAP实现细节相关的内容对用户隐藏起来。   gSOAP的编译器能够自动的将用户定义的本地化的C或C++数据类型转变为符合XML语法的数据结构,反之亦然。这样,只用一组简单的API就将用户从SOAP细节实现工作中解脱了出来,可以专注与应用程序逻辑的实现工作了。gSOAP编译器可以集成C/C++和Fortran代码(通过一个Fortran到C的接口),嵌入式系统,其他SOAP程序提供的实时软件的资源和信息;可以跨越多个操作系统,语言环境以及在防火墙后的不同组织。   gSOAP使编写web服务的工作最小化了。gSOAP编译器生成SOAP的代码来序列化或反序列化C/C++的数据结构。gSOAP包含一个WSDL生成器,用它   来为你的web服务生成web服务的解释。gSOAP的解释器及导入器可以使用户不需要分析web服务的细节就可以实现一个客户端或服务端程序。   下面是gSOAP的一些特点:   ×gSOAP编译器可以根据用户定义的C和C++数据结构自动生成符合SOAP的实例化代码。   ×gSOAP支持WSDL 1.1, SOAP 1.1, SOAP 1.2, SOAP RPC 编码方式以及 literal/document 方式.   ×gSOAP是少数完全支持SOAP1.1 RPC编码功能的工具包,包括多维数组及动态类型。比如,一个包含一个基类参数的远程方法可以接收客户端   传来的子类实例。子类实例通过动态绑定技术来保持一致性。   ×gSOAP 支持 MIME (SwA) 和 DIME 附件包。   ×gSOAP是唯一支持DIME附件传输的工具包。它允许你在保证XML可用性的同时能够以最快的方式(流方式)传递近乎无大小限制的二进制数据   。   ×gSOAP 支持 SOAP-over-UDP。   ×gSOAP 支持 IPv4 and IPv6.   ×gSOAP 支持 Zlib deflate and gzip compression(for HTTP, TCP/IP, and XML file storage)。   ×gSOAP 支持 SSL (HTTPS)。   ×gSOAP 支持 HTTP/1.0, HTTP/1.1 保持连接, 分块传输及基本验证。   ×gSOAP 支持 SOAP 单向消息。   ×gSOAP 包含一个 WSDL 生成器,便于web服务的发布。   ×gSOAP 包含一个WSDL解析器(将WSDL转换为gSOAP头文件),可以自动化用户客户端及服务端的开发。   ×生成可以单独运行的web服务及客户端程序。   ×因为只需要很少内存空间,所以可以运行在类似Palm OS, Symbian, Pocket PC的小型设备中。   ×适用于以C或C++开发的web服务中。   ×跨平台:Windows, Unix, Linux, Mac OS X, Pocket PC, Palm OS, Symbian等。   ×支持序列化程序中的本地化C/C++数据结构。   ×可以使用输入和输出缓冲区来提高效率,但是不用完全消息缓冲来确定HTTP消息的长度。取而代之的是一个三相序列化方法。这样,像64位   编码的图像就可以在小内存设备(如PDA)中以DIME附件或其他方式传输。   ×支持C++单继承,动态绑定,重载,指针结构(列表、树、图、循环图,定长数组,动态数组,枚举,64位2进制编码及16进制编码)。   ×不需要重写现有的C/C++应用。但是,不能用unions,指针和空指针来作为远程方法调用参数的数据结构中元素。   ×三相编组:1)分析指针,引用,循环数据结构;2)确定HTTP消息长度;3)将数据序列化位SOAP1.1编码方式或用户定义的数据编码方式。   ×双相编组:1)SOAP解释及编码;2)分解“forward”指针(例如:分解SOAP中的href属性)。   ×完整可定制的SOAP错误处理机制。   ×可定制的SOAP消息头处理机制,可以用来保持状态信息   2 gSoap2.2版与gSOAP 2.1版(或以前版本)的不同   如果你是从2.1版升级到2.2或以后版本,请注意这些变化。   为了能够分离传输、内容编码、映射中的接收/发送设置,改变了运行时选项及标志。这些标志分布再四个类中:传输(IO),内容编码(ENC   

16,473

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧