暗藏的this操作符
对非动态核心成员表达式而言，它随身携带了三个暗藏的”this”操作符，这引致它无法满足用户Win32反弹表达式亲笔签名的明确要求，这种的结论是：三个非动态核心成员表达式，无法做为三个不合法的Win32反弹表达式。
幸运的是，基本上大部份的反弹表达式都提供更多了许多方式来交互初始化语句。你能将那个”this”操作符做为三个语句自然环境来解构标识符，下面是三个范例：
有许多反弹表达式亲笔签名将它的第三个模块做为命令语句的模块(也叫作”引用统计数据”)。不巧的是，那个暗藏的”this”操作符也刚好是第三个模块。简述他们以后有关初始化签订合同的该文，能晓得对核心成员表达式的__stdcall初始化签订合同也刚好相匹配他们市场预期的栈产业布局。下面他们看三个WAITFORTIMERCALLBACK的范例：
请注意：”thiscall”初始化签订合同无法相匹配下面的情景，但三个”__stdcall”却能。幸运地的是，C++足够多精明，它能辨识那个this操作符，并对下面的动态成员表达式s_ThreadProc展开强化。
如果你有机会观察一下C++为s_ThreadProc生成的汇编标识符，则你会发现：表达式的实现实际上是三个跳转指令，因为C++已经意识到了两种不同的初始化签订合同，所以这里不需要做任何的翻译工作，只是跳转即可。
有些人可能想着更进一步：直接对CreateThread的第二个模块强制转换为LPTHREAD_START_ROUTINE，这种就能完全不需要定义s_ThreadProc那个表达式了。我强烈建议不这么做：因为我看到很多人都曾在转换表达式操作符那个上吃过亏（有关那个议题，我后面会专门讲一讲）。
总结
在下面的标识符中，虽然他们考虑到了三个__stdcall初始化签订合同，但他们并没有依赖它们。如果初始化签订合同的巧合无法像市场预期那样的工作，则标识符依然会正常工作。那个对将标识符移植到其他架构的时候很重要，特别是当那个架构没有下面所述的初始化签订合同的巧合的时候。
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多有关Windows的小知识，对广大Windows平台开发者而言，确实十分有帮助。本文来自：《Why do member functions need to be “static” to be used as a callback?》
