今天做一个成绩管理系统的并发引擎,用Qt做的,仿照QtConcurrent搞了个模板基类。这里为了隐藏细节,隔离变化,把并发的东西全部包含在模板基类中。子类只需注册需要并发执行的入口函数即可在单独线程中执行。最终目标是,继承的业务逻辑类外部调用时有两个接口可选,调用syncRun同步执行;调用由引擎自动生成的asyncRun就异步执行。最终自动生成asyncRun的模板基类没能实现,主要原因是mingw对this处理的太有问题了!!原本以为编译器问题,后来才知道成员函数指针和this指针如此特殊,对此篇文章反感者请移步文章末尾直接看好文。
/*!
author LiuBao
date 2011/3/8
rief 汇集了各种成员函数指针的错误用法
*/
#include <iostream>
#include <conio.h>
using namespace std;
class B;
class A
{
public:
A() {cout << "A::this->" << this << endl;}
void runA()
{
/* 错误的类型转换,拜一篇烂文所赐用上的 */
union
{
void *from; //void*类型
void (A::*to)(int); //A的成员函数指针类型
void (*to2)(A*, int); //C的函数指针类型,第一个参数是A*类型,用于传this
}ut;
ut.from = childFuncPtr;
(this->*ut.to)(0); //错误调用,用父类指针,以成员函数指针方式调用子类的成员函数
/* 微软运行时库检测到运行时错误 */
ut.to2(this, 1); //错误调用,用C语言风格的函数指针,直接把this作为第一个参数传入调用子类的成员函数
}
template<typename FromType>
void saveFuncPtr(FromType addr)
{
/* 错误的类型转换,拜一篇烂文所赐用上的 */
union
{
FromType from; //任意成员函数指针类型
void *to; //void*类型
}ut;
/* 把地址转换为void*保存到childFuncPtr */
ut.from = addr;
childFuncPtr = ut.to;
}
protected:
void *childFuncPtr; //错误使用,由于长度可能不同,void*不可以用来保存任意成员函数地址
};
class B : public A
{
public:
B()
{
cout << "B::this->" << this << endl; //打印B的this指针
this->saveFuncPtr(&B::testThis); //保存B::testThis地址到父类的void*成员变量
}
void runB()
{
/* 错误的类型转换,拜一篇烂文所赐用上的 */
union
{
void *from; //void*类型
void (B::*to)(int); //类B的成员函数指针类型
void (*to2)(B*, int); //C语言的函数指针类型,第一个参数是B*类型,用于传this
}ut;
ut.from = childFuncPtr;
testThis(2); //直接调用成员函数
(this->*ut.to)(3); //错误调用,用函数指针调用成员函数
/* 微软运行时库检测到运行时错误 */
ut.to2(this, 4); //错误调用,用C语言风格的函数指针,直接把this作为第一个参数传入调用子类的成员函数
}
void testThis(int i) {cout << i << " -> " << this << endl;}
};
int main()
{
B b;
b.runA();
b.runB();
_getch();
return 0;
}
本例旨在测试各编译器对this的处理情况,其中有错误用法,请勿在实际项目中仿照使用!测试平台Win7x64,各编译器使用默认参数
gcc version 4.4.0 (GCC) 左debug右release。可见用debug版中,函数指针方法调用成员函数,成员函数中的this指针是错的!
用于 80x86 的 Microsoft (R) 32 位 C/C++ 优化编译器 16.00.30319.01 版左debug右release。debug版本有健全的运行时检查,so,release时就可以放心的给出异常值了。vs处理C语言风格调用成员函数给出运行时错误,这一点很令人赞赏!
这是把用C语言风格调用成员函数两处注释掉后vs编译运行结果,左debug右release。this指针完全正常。Intel(R) C++ Compiler XE for applications running on IA-32, Version 12.0.0.063 Build 20100721的运行结果与vs2010几乎完全一样,debug版本一样有运行时错误,可见是微软的运行时库在起作用。但是release版本直接崩溃,也许跟优化方式有关?微软自家编译器链自家库确实有优势,呵呵~同样,去掉两处C风格调用,this指针完全正常。
Embarcadero C++ 6.31左debug右release。所有调用均输出正确的this值!
总结:最费解的是mingw的结果(同学linux下用gcc测试结果一样)。父类与子类有同样的this值,同样的函数地址,父类指针直接调用子类成员函数居然可以离谱成这样!看来,奇技淫巧最终带来的后果是各种不确定,不要尝试用父类指针调用子类成员函数,更不要使用C语言的函数指针强制传递this指针!!
后续:现在才明白,我是试图用模板实现自动类型推导的委托-_-! 推荐3篇该方面的好文:
http://www.cnblogs.com/codingmylife/archive/2011/03/08/1976720.html
备注:在我使用的环境(VC6)里,类的成员函数的默认调用约定是__thiscall; 关于这个调用约定,请注意在MSDN中的描述:“Arguments are pushed on the stack from right to left, with the this pointer being passed via register ECX, and not on the stack, on the x86 architecture.”
注意这段话表达的意思非常重要,在X86上,this指针是通过ECX传递的,而不是通过栈传递的。
在MSDN中还有比较重要的信息是,__thiscall 在VS2005.net之前的版本中无法显示指定。
在IPF芯片和X64的机器上,__thiscall会被编译器接受但是被忽略。所以我想这是你第一个测试环境没有弹出错误对话框的原因。
http://blog.csdn.net/hifrog/archive/2004/07/03/33352.aspx
这篇里“成员函数指针实现”一节提到的:
编译器 选项 int DataPtr CodePtr Single Multi Virtual Unknown
MSVC 无 4 4 4 4 8 12 16
其中 void*属于DataPtr,静态成员函数指针也就是C语言的普通函数指针属于CodePtr,Multi是多重继承下的成员函数指针,Virtual是虚继承下的成员函数指针。
如果我把多重继承下的成员函数指针8字节长赋值给了void*(4字节长)就丢失了一部分数据。我没试过,文中这么写的。