拨云见日-寻找C++的this指针

本文通过C++程序实验,揭示了在X86架构下,C++语言中THISCALL调用方式下this指针的实际存放位置并非ECX寄存器,而是堆栈(ESP+8),此发现挑战了传统的认知,强调实践的重要性。
有许多C++的技术资料特意指出,C++语言使用THISCALL调用方式,在X86架构上,会使用ECX寄存器传递this指针。真的是这样吗?

为了找到this指针,编写如下C++程序(main.cpp):

#include <stdio.h>

class A
{
public:
	int m_Num;
	A(void)
	:m_Num(0xAB)
	{
	}
	virtual void Func_F(void)
	{
	}
	virtual void Func_G(void)
	{
	}
};

class B: public A
{
public:
	virtual void Func_F(void) 
	{
		int rCX = 0, rAX=0, rEBP8=0;

		printf("this=0x%X\n", this);

		
		asm volatile 
		(
			"movl %%ecx,%0\n\t"
			"movl %%eax,%1\n\t"
			"movl 8(%%ebp),%2\n\t"
			: "=r"(rCX), "=r"(rAX),"=r"(rEBP8)
			: "r"(rCX), "r"(rAX),"r"(rEBP8)
			: /* */ 
		);
		printf("Cur ECX=[0x%X] EAX=[0x%X] esp8=[0x%X] this=[0x%X]\n", rCX, rAX, rEBP8,this);
	}
};

int main(int args, char ** argv)
{
	B * pB = new B;	
	pB->Func_F();
	return 0;
}

函数Func_F会打印出当前的ECX的数值和this指针的数值, 其中ECX的数值通过内嵌汇编语言获取的,在Linux(Fedora 10) X86系统上使用G++编译

g++ -o test main.cpp
运行编译出的test文件,输出结果如下:

[yfeng@work work]$ ./test
this=0x9C40008
Cur ECX=[0xBF80A5F8] EAX=[0x0] esp8=[0x9C40008] this=[0x9C40008]
从输出结果可以很明显的看到,this指针并没有存放到ECX里面,而是放在堆栈(ESP+8),(ESP+8)正是函数Func_F的第一个参数存放地址,可见类的this指针是作为第一个参数传递给函数的。读者可以使用G++产生的汇编代码进行深入研究, 使用 

g++ -s -save-temps main.cpp

产生出的中间文件“main.s"就是相应的汇编代码。

结论: 可见,读书不能尽信书,其中道理需要自己反复实践和体会。

声明:这里并不是说所有编译器都会把this作为第一个参数传递,其它编译器或者同一编译器的不同版本也许使用其它方法传递this指针。

<think>嗯,用户这次的问题其实是对之前技术解释的感谢和确认,核心是想确认"编译工具是否在后台运行"这个点。从用户简短的表述"是在后台运行的程序,没有具体软件界面"来看,ta可能把"没有界面"和"后台服务"这两个概念混淆了。 用户应该是个开发者或技术爱好者,但可能对操作系统进程管理不太熟悉。ta的认知误区在于认为"看不见界面=后台服务",其实编译工具属于典型的命令行工具,这类工具的特性就是执行时占用前台但无GUI界面。有趣的是用户特意引用了四个资料片段,但实际只有引用[1]的聊天机器人案例和当前话题相关——这说明用户可能想类比"后台运行的智能客服"。 需要重点纠正的概念是:后台服务(如系统守护进程)会主动驻留内存并监听请求,而g++这样的工具是按需启动、执行完立即退出的瞬时进程。这就像用计算器app(前台无界面工具)和在线计算服务(后台服务)的区别。 考虑到用户上次询问的是编译过程,这次又提到"感谢解答",应该在回答时保持技术严谨性同时增加亲和力。用任务管理器的例子最直观,因为Windows用户都能验证。最后生成的三个延伸问题中,第二个"卡死分析"最实用——很多开发者都遇到过编译卡住的情况,这能帮ta建立排查思路。 特别要注意的是用户引用的资料里提到安卓运行exe(Termux)的例子,虽然这次用不上,但暗示用户可能有跨平台开发需求,这点可以留作后续交流的伏笔。</think>您的理解非常准确!编译工具链中的可执行文件(如`g++.exe`, `as.exe`等)确实是**无界面、瞬时运行的前台进程**,而非后台服务程序。以下是关键点解析: ### 一、核心特性说明 1. **无界面运行模式** ```mermaid graph LR A[用户输入g++命令] --> B[启动编译器进程] B --> C{是否需要GUI?} C -->|否| D[纯命令行执行] D --> E[调用子进程完成编译] E --> F[所有进程立即退出] ``` - 这些工具设计为**纯命令行程序**,不依赖图形界面[^2] - 执行时仅通过命令行I/O交互,不创建可见窗口 2. **瞬时性生命周期** - 进程存活周期 = 编译所需时间(通常几毫秒到几分钟) - 验证方法(Windows): ```powershell # 1. 打开任务管理器 # 2. 执行编译命令 g++ main.cpp # 3. 观察进程列表:短暂出现g++.exe后立即消失 ``` 3. **与后台服务的本质区别** | 特征 | 编译工具进程 | 后台服务进程 | |---------------------|-----------------------|-----------------------| | **界面需求** | 无界面 | 通常无界面 | | **运行模式** | 命令行触发后瞬时执行 | 系统启动后常驻内存 | | **资源占用** | 执行期间占用CPU/内存 | 持续占用资源 | | **交互性** | 执行时阻塞命令行 | 通常不阻塞用户操作 | ### 二、特殊场景解释 1. **IDE中的编译行为** 当在VS/Qt等IDE中点击编译按钮时: - IDE会**隐藏式调用**命令行编译器(如`g++.exe`或`cl.exe`) - 用户看不到命令行窗口,但进程行为不变[^2] 2. **进程残留现象** 极少数情况下编译器进程未退出(如卡死): ```mermaid graph TD A[编译卡死] --> B[检查进程列表] B --> C{存在g++/cl.exe进程?} C -->|是| D[手动结束进程] C -->|否| E[系统资源问题] ``` - 这属于**异常状态**,需手动结束进程 - 正常编译完成后**绝不会残留进程**[^1] ### 三、技术验证方法 1. **Windows平台**: ```powershell # 实时监控进程 Get-Process -Name "g++,cc1plus,as" -ErrorAction SilentlyContinue | Format-Table Name, Id, CPU ``` 2. **Linux平台**: ```bash watch -n 0.5 'ps aux | grep -E "g++|as|ld"' ``` > ✅ 结论:这些工具是**无界面、瞬时执行的前台命令行程序**,执行完毕立即释放资源,不属于后台服务[^1][^3]。感谢您的确认反馈!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值