简单问题,答对送分!

muche 2003-08-13 05:01:51
__stdcall 这是个什么符号?有什么作用?
...全文
55 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
zlj617 2003-08-14
  • 打赏
  • 举报
回复
up
muche 2003-08-14
  • 打赏
  • 举报
回复
o
muche 2003-08-14
  • 打赏
  • 举报
回复
__cdecl,在调用一个函数的时候,参数入栈,调用完以后,由调用该函数的 代码维护栈
__stdcall,调用该函数栈的维护工作是由函数自已来完成的 不需要由调用该函数代码进行栈的维护
FAICHEN 2003-08-13
  • 打赏
  • 举报
回复
调用约定这个问题我参与了5次以上了
实际上就是参数压栈顺序及其谁来做释放者的问题
一般情况下,调用约定相同就没问题
xiaohedou 2003-08-13
  • 打赏
  • 举报
回复
_stdcall与_cdecl主要是调用的顺序问题,一般在c与pascal的协调上常用。
muche 2003-08-13
  • 打赏
  • 举报
回复
good
kwiner 2003-08-13
  • 打赏
  • 举报
回复
gz
guanjinke 2003-08-13
  • 打赏
  • 举报
回复
_stdcall是Pascal程序的缺省调用方式,通常用于Win32 Api中,函数采用从右到左的压栈方式,自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀,在函数名后加上"@"和参数的字节数。

2、C调用约定(即用__cdecl关键字说明)按从右至左的顺序压参数入栈,由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的(正因为如此,实现可变参数的函数只能使用该调用约定)。另外,在函数名修饰约定方面也有所不同。

_cdecl是C和C++程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码,所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。

3、__fastcall调用约定是“人”如其名,它的主要特点就是快,因为它是通过寄存器来传送参数的(实际上,它用ECX和EDX传送前两个双字(DWORD)或更小的参数,剩下的参数仍旧自右向左压栈传送,被调用的函数在返回前清理传送参数的内存栈),在函数名修饰约定方面,它和前两者均不同。

_fastcall方式的函数采用寄存器传递参数,VC将函数编译后会在函数名前面加上"@"前缀,在函数名后加上"@"和参数的字节数。

4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器,参数从右到左压。thiscall不是关键词,因此不能被程序员指定。

5、naked call采用1-4的调用约定时,如果必要的话,进入函数时编译器会产生代码来保存ESI,EDI,EBX,EBP寄存器,退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符,故必须和_declspec共同使用。

关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前,也可以在编译环境的Setting...\C/C++ \Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时,直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd,即__cdecl。

要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定,至于函数名修饰约定,可以通过其它方法模仿。还有一个值得一提的是WINAPI宏,Windows.h支持该宏,它可以将出函数翻译成适当的调用约定,在WIN32中,它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs
muche 2003-08-13
  • 打赏
  • 举报
回复
有点明白,但还是不太明白,那种资料上有讲这个的?
zhucde 2003-08-13
  • 打赏
  • 举报
回复
参看MSDN
littlebao 2003-08-13
  • 打赏
  • 举报
回复
__cdecl,在调用一个函数的时候,参数入栈,调用完以后,由调用该函数的
代码维护栈
__stdcall,调用该函数栈的维护工作是由函数自已来完成的
不需要由调用该函数代码进行栈的维护
guanjinke 2003-08-13
  • 打赏
  • 举报
回复
指示编译器编译函数的方式,是从左到右还是从右向左
1.简述计算机网络和互联网的定义 答:计算机网络是一些互相连接的、自治(自主)的计算机的集合。为用户提供资源共享和连通性。 互联网是 2.OSI、TCP/IP协议体系结构分为几层,它们每层的名称是什么?请你比较对比这两个体系结构的异同。 请简述ISO/OSI参考模型每层的名称和主要功能。 (1)物理层:完成原始比特传输; (2)数据链路层:完成相邻结点之间的可靠数据传输; (3)网络层:完成任意两台主机之间的数据传送; (4)传输层:完成两台主机上两个进程之间数据通信; (5)会话层:完成进程之间的会话管理; (6)表示层:完成数据格式转换以及数据加密、压缩等工作; (7)应用层:是用户访问网络的接口。 请简述TCP/IP协议体系结构参考模型每层的名称和主要功能。 1.网络接口层 2.网络互连层 3.传输层 4.应用层 3.试比较电路交换、报文交换、分组交换的主要有缺点? 电路交换:整个报文的比特流连续地从源点直达终点,好像在一个管道中传送, 经过通信路径上的线路资源独占; 优点:通信实时性强,适用于交互式会话类通信; 缺点:1. 对突发性通信不适应,通信线路的利用率较低。2.建立连接时间长,系 统不具有存储数据的能力,不能平滑流量。 报文交换:整个报文先传送到相邻结点,全部存储下来后查找转发表,转发到下 一个结点。 优点:无需预先分配传输带宽,在传送突发数据时可提高整个网络的信道利用率; 缺点:时延较长,灵活性较差。 分组交换:单个分组传送到相邻结点,存储下来后查找转发表转发到下一个结点。 优点: 高效 动态分配传输带宽,对通信链路是逐段占用。 灵活 以分组为传送单位和查找路由。 迅速 不必先建立连接就能向其他主机发送分组。 可靠 保证可靠性的网络协议;分布式的路由选择协议使网络有很好的生存 性。 缺点:分组在各结点存储转发时需要排队,会造成一定的时延。分组必须携带的 首部(里面有必不可少的控制信息)也造成了一定的开销。很难提供服务质量。 4.给出TCP和UDP的英文全称和中文解释。简要比较它们的不同。 UDP(User Datagram Protocol -1分,用户数据报协议-1分):无连接的、面向报文的、尽最大努力交付的(不保证可靠)、没有拥塞控制的、首部开销小(1分) TCP(Transmission Control Protocol-1分, 传输控制协议-1分):面向连接的、面向字节流的、可靠交付的、提供全双工通信(2分) 5.解释以下概念:计算机网络体系结构、协议栈、协议数据单元、基带信号、带通信号。 计算机网络体系结构:计算机网络的各层及其协议的集合。或:计算机网络及其构件所应完成的功能的精确定义(2分) 协议栈:指网络中各层协议的总和。计算机网络的体系结构通常分为几层,几个层次画在一起很象一个栈的结构。(2分) 协议数据单元:对等层次之间传送的数据单位(1分) 基带信号:来自信源的基本频带信号(1分) 带通信号:经过载波调制后的信号(1分)。 6.简述IP地址与硬件地址的区别。 IP地址是网络层和以上各层使用的地址(1分),是一种逻辑地址,IPv4地址32位(4字节)(1分),IPv6地址128位(16字节)(1分) MAC地址是数据链路层的和物理层使用的地址(1分),是一种物理地址。MAC地址长度为48位(6字节)(1分) IP地址放在IP数据报的首部(1分),而MAC地址放在MAC帧的首部。(1分) 7.什么是计算机网络,计算机网络协议的三要素是什么,各要素的含义什么 计算机网络:一些互相连接的、自治的计算机的集合。(1分) 语法(1分): 数据与控制信息的结构或格式 。 (1分) 语义(1分): 需要发出何种控制信息,完成何种动作以及做出何种响应。 (1分) 同步(1分): 事件实现顺序的详细说明。(1分) 8. 试简述IEEE802.3标准以太网(CSMA/CD)的介质访问控制的工作原理(包括发送端、接收端及冲突处理的原理)。 “多点接入”表示许多计算机以多点接入的方式连接在一根总线上。(1分) “载波监听”是指每一个站在发送数据之前先要检测一下总线上是否有其他计算机在发送数据,如果有,则暂时不要发送数据,以免发生碰撞。 (2分) “碰撞(冲突)检测”就是计算机边发送数据边检测信道上的信号电压大小。(2分) 一旦发现总线上出现了碰撞(冲突),就要立即停止发送,免得继续浪费网络资源,然后等待一段随机时间后再次发送。(2分) 或:先听后发,边听边发,碰撞停止,延迟重发 9.简述透明网桥的工作原理及其学习算法。 (1).网桥收到一帧后先进行自学习(1分)。查找转发表中与收到帧的源地址有无相匹配的项目。如没有,就在转发表中增加一个项目(源地址、进入的接口和时间)(1分)。如有,则把原有的项目进行更新。(1分) (2)转发帧。查找转发表中与收到帧的目的地址有无相匹配的项目。(1分) 如没有,则通过所有其他接口(但进入网桥的接口除外)进行转发(扩散)。(1分) 如有,则按转发表中给出的接口进行转发。(1分) 若转发表中给出的接口就是该帧进入网桥的接口,则应丢弃这个帧(因为这时不需要经过网桥进行转发)。(1分) 1、什么是计算机网络体系结构?计算机网络为什么要分层? 答: 计算机网络中各层及各层协议的集合称为计算机网络体系结构(3分)。分层的原因基于以下几点:(2分) 1)各层之间是独立的。 2)灵活性好。 3)结构上可分割开。 4)易于实现和维护。 能促进标准化工作。 2、试简述IEEE802.3标准以太网的介质访问控制的工作原理(包括发送端、接收端及冲突处理的原理)。 答: (1)工作站要发送数据时,先侦听信道是否有载波,如果有,表示信道忙,则继续侦听,直至检测到空闲,立即发送数据;(2分) (2)在发送数据过程中进行冲突检测,如果在冲突窗口内没有发生冲突,则表示数据发送成功,否则立即停止发送,并采用二进制指数回退算法,等待一个随机时间后在重复发送过程;(2分) (3)对于接收方,则根据数据包的校验和正确与否和物理地址是否为自己来决定是否将数据交给上层协议。(1分) 3、简要说明计算机A与B采用TCP协议通信时,连接建立过程。 答: TCP通讯双方建立连接过程称为3次握手,即双方共计发送三次报文的通讯(2分),若A主机主动向B主机通讯,则其连接建立过程如下(每点1分): 1)A发送报文,其SYN为1; 2)B发送报文,其SYN为1,ACK为1; 3)A发送报文,其ACK为1 4、什么叫流量控制,试简述TCP的流量控制机制,UDP协议中有流量控制吗? 答: (1)为了防止快速的发送设备发出的数据过多,导致慢速的接收设备处理不过来而发生大量数据丢失(淹没慢速的接收设备)所采取的限制措施称为流量控制。(3分) (2)在面向连接的TCP协议中,TCP包中有一个Window size 字段,接收方可以通过该字段告诉发送方,自己还有多少个接收缓冲区,极端情况下,当接收方不能再接收数据时,把该字段设置为0,从而发送方可以根据该字段的值来调整发送数据的大小或速率。(1分) (3)UDP协议中无流量控制。(1分) 3. 常用的信道复用技术有哪些? 1).FDM: Frequency Division Multiplexing 频分复用(1分) 2).TDM:Time Division Multiplexing 时分复用、STDM: Statistic TDM统计时分复用(2分) 3).WDM: Wavelength Division Multiplexing 波分复用(1分) 4).CDM: Code Division Multiplexing 码分复用:(1分) 5. 简单对比虚电路服务和数据报服务 每答对1个对比方面得1分,最高得5分。 对比的方面 虚电路服务 数据报服务 思路 可靠通信应当由网络来保证 可靠通信应当由用户主机来保证 连接的建立 必须有 不需要 终点地址 仅在连接建立阶段使用,每个分组使用短的虚电路号 每个分组都有终点的完整地址 分组的转发 属于同一条虚电路的分组均按照同一路由进行转发 每个分组独立选择路由进行转发 当结点出故障时 所有通过出故障的结点的虚电路均不能工作 出故障的结点可能会丢失分组,一些路由可能会发生变化 分组的顺序 总是按发送顺序到达终点 到达终点时不一定按发送顺序 端到端的差错处理和流量控制 可以由网络负责,也可以由用户主机负责 由用户主机负责 2、简述Link-State路由算法的工作过程及其特点。 答,应该围绕发送时机、发送对象、发送内容3方面展开讲解。 3.网络体系结构中各层传输的数据单位: 物理层:比特(位)bit 数据链路层:帧frame 网络层:分组(包)packet, 或IP 分组,IP 数据报 运输层:TCP:报文段segment, UDP:用户数据报user datagram 3. 网络体系结构中各层的主要设备 物理层:中继器(转发器)repeater、集线器hub(扩大冲突域)、网卡NIC(网 络适配器Adapter) 数据链路层:网桥bridge(会产生广播风暴)、交换机switch(2 层)、网卡NIC(网 络适配器adapter) 网络层:路由器 router (可以抑制广播风暴,丢弃广播分组) 运输层及以上:网关gateway 4. 透明传输的解决方法 字节填充或字符填充:发送端的数据链路层在数据中出现控制字符,则在其前面插入一个转 义字符;接收端的数据链路层在将数据送往网络层之前删除这个插入的转义字符。 零比特填充(位填充):在发送端,先扫描整个信息字段,只要发现有 5 个连续 1,则立即 填入一个 0;在接收端,对帧中的比特流进行扫描,每当发现 5 个连续1 时,就把这 5 个 连续 1 后的一个 0 删除。 3. 端口号(熟知端口号、登记端口号、短暂端口号) :P182-184 FTP :20、21 端口;Telnet:23 端口;SMTP:25 端口;HTTP:80 端口 DNS:53 端口;DHCP :67、68 端口;TFTP:69 端口;SNMP:164 端口 4. TCP 套接字 把 IP 地址和端口号合起来就是套接字(socket) 套接字= (IP 地址: 端口号) 2.解决IPv4 地址耗尽的措施有哪些? 1).子网划分,提高IP 地址利用率,减少IP 地址的浪费 2).无类别编址 CIDR,使 IP 地址的分配更加合理 3).DHCP,分时利用IP 地址 4).NAT,一个公用IP 地址代理多个私有地址 5).使用更大地址空间的新版本IP 协议,如IPv6.
首先简要介绍一下目前的站点功能吧。右图就是本站的主页效果,我做得很简洁,没有用太多花哨的图片,也没有用走马灯。明眼人一看就知道这是基于ASP.NET MVC而开发的Web应用程序,使用了Bootstrap。不错,基本答对!需要强调的是,这个博客站点以及后端的RESTful服务,全部都是基于ASP.NET Core完成的,.NET Core运行时版本为1.1.0,运行在Docker容器中。哎,说着说着又到技术上了,功能还没介绍完呢。说到功能,目前功能很简单:主页列出了我自己原创或者翻译的所有文章,读者可以注册用户帐号,注册用户可以发表评论,也可以在用户管理页面中更改自己的昵称。好了,目前功能就这么多,别看功能少,我可是前前后后陆陆续续花了2个月的时间,才做到目前这个样子。当然,我会继续更新这个站点,让它的功能变得更加完善。提到ASP.NET Core,有没有吊起你的技术胃口呢?不用着急,接下来我就介绍一下整个站点中各部分的技术选型,看完后,或许你会知道为什么我花了2个月的业余时间,才整出来这么个简单的玩意儿。站点技术介绍整体架构整个网站所采用的所有基础设施全部运行在微软云(Windows Azure)中,使用了部分托管资源,以及一些非托管的Azure VM。大致情况如下:图片存储服务:由Azure Blob Storage Service托管数据库系统:由Azure SQL Database托管(未启用Geo-Replication,因为没钱)邮件服务:由Azure SendGrid Account托管(Pricing Tier为F1,每月可以免费发送25000封邮件)应用服务器:基于Azure构建的Ubuntu 16.04.1 LTS虚拟机,运行了两个Docker容器:blog-web和blog-service,分别托管前端Web站点和后端RESTful服务。后端RESTful API服务没有做任何认证和授权,Web站点通过内部子网访问RESTful API服务,Docker容器运行在非托管环境中持续集成系统:Jenkins,基于Azure构建的Windows Server 2012 R2一台(Master),和一台Ubuntu 16.04.1 LTS(Slave)。站点的前端和后端都在后者(Ubuntu)中完成编译、打包以及Docker镜像的发布,实现了一步到位的部署方式代码库:Github有人会问:为什么使用了非托管的Azure VM环境运行应用系统?我也考虑过这个问题,理论上讲,基于云的系统架构最好选用托管的PaaS服务,这样不仅可以得到纯天然的高可用性(包括灾备,比如AWS的跨AZ部署,某些服务跨区域的可用性,以及负载均衡),而且还可以得到专业的技术支持。只有当存在老系统向云迁移的需求,并需要迎合老系统的特定运行环境要求时,才考虑使用IaaS服务。虽然虚拟机等这些资源是由Azure负责创建并运行的,在这一层面Azure可以保证虚机的可用性,但虚机内部运行的任何程序的状态,以及所使用的数据,Azure等云服务是无从得知的,对这部分东西的监控也会变得很麻烦。出于安全考虑,通常云服务供应商是不会,也不应该获得类似虚机内部的客户程序的运行数据的,使用虚拟机服务所产生的程序运行风险,客户需要自己承担。这也就是著名的责任共担原则。看起来用虚拟机运行应用不是太靠谱嘛,然而我却选择这么使用了。有几个原因:为何不使用Azure Web App?一方面Jenkins做自动化部署,直接把编译好的应用推送到Azure Web App中好像不是太顺手,要写一些PowerShell的代码,可是我的编译系统是Linux,不过现在已经有Linux版的PowerShell了,而且Azure SDK Command Line Interface也有Linux版,所以这个理由有点牵强,更合理的解释是:劳资不会!另一方面,我没有在服务端做认证和授权,仅通过子网向外界提供服务,所以我希望我的Web App也运行在子网内部,然后向外暴露80端口供外界访问。这样一来,Azure Web App又如何部署到我自己的子网内?这是一个技术问题,我相信一定有解决方案,但是我也没太多时间和精力去细究如何实现,自己的第一反应也无非是将前后端全部部署在Azure Web App中,然后打开后端的认证机制。但这样做又要花一些额外的工夫。好吧,还是这个理由:劳资不会为何不使用Azure Container Service?Azure Container Service会在你指定的Resource Group(资源组)中创建一整套网络部署,包括好几台虚拟机、公网IP、两个负载均衡器等等,我想你一定知道我为什么没有选择Azure Container Service了,原因就是:劳资没钱理由够充分吧?微软Windows Azure提供的这些服务都很赞,我没选不是说它们不好用,而是出于自己的实际情况考虑:某些服务的学习成本经济成本暂时没必要做到99.99999%的高可用率即使应用挂了,恢复的成本很小:数据完全不需要恢复,托管的SQL Database、Blob Storage会保证我的数据不丢失,应用程序恢复也很简单:重新运行Docker容器就完事儿OK,从整体架构上看,我的选择即是如此而已,这样的选择当然不一定完全正确,但我觉得至少合适,仅供参考。下面附上本站点的整体架构图。作几点注解:三台VM位于同一个Virtual Network的subnet中,每台VM的虚拟网卡上都套有独立的Network Security Group(NSG),在NSG上设置了Inbound/Outbound Endpoints,严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问Windows Server 2012 VM宿主了Jenkins Master,以及Seq日志服务。它向公网暴露8080端口和5342端口,分别用于访问Jenkins服务和Seq管理界面第一台Ubuntu VM运行了Jenkins Slave,它不向公网暴露任何端口,仅向Jenkins Master机器暴露22端口,用于Jenkins Slave Agent的执行调度第二台Ubuntu VM运行了博客系统的两个Docker容器:前端应用程序blog-web和后端RESTful API服务程序blog-service。web通过子网IP地址访问service,VM仅向公网暴露80端口,后台service无法从公网访问两个Docker容器所运行的应用(blog-web和blog-service)都可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务整个部署的拓扑结构有可能不太合理,比如没有做负载均衡,没有使用托管的应用宿主服务(比如Azure Web App、Container Service等),没有使用Scaleset。因为目前没必要而且没钱更多说明,详见作者的博客:http://daxnet.me/blogposts/post/221 标签:daxnet

16,472

社区成员

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

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

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