MFC's message map, no need of &?
-
It's syntax that we have to put '&' right before pointer to member function. For example here.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};int main(){
fpop pFunc;
pFunc = &Test::Op1; // we must need &return 0;}
However, when I take a look at ON_COMMAND(or any other messages) in MFC, it seems a bit different from what I think is right. VS6.0 is okay. It follows the right syntax as you see below. You can clearly see & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },
// ON_COMMAND(id, OnFoo) is the same as
// ON_CONTROL(0, id, OnFoo) or ON_BN_CLICKED(0, id, OnFoo)But in VS2008, it goes a bit weird. There is no & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
static_cast (memberFxn) },
// ON_COMMAND(id, OnBar) is the same as
// ON_CONTROL(0, id, OnBar) or ON_BN_CLICKED(0, id, OnBar)Moreover, in spite of the fact that there is no & before memberFxn, each line below works perfectly. 1. ON_COMMAND(ID_APP_ABOUT, CSingleApp::OnAppAbout) // & 2. ON_COMMAND(ID_APP_ABOUT, &CSingleApp::OnAppAbout) // no & I tried to find why, and I was curious if it could be because of static_cast<> but it turned out that static_cast has nothing to do with it. So I am wondering why in VS2008 I have 2 choices where I put & or I don't have to put &.
-
It's syntax that we have to put '&' right before pointer to member function. For example here.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};int main(){
fpop pFunc;
pFunc = &Test::Op1; // we must need &return 0;}
However, when I take a look at ON_COMMAND(or any other messages) in MFC, it seems a bit different from what I think is right. VS6.0 is okay. It follows the right syntax as you see below. You can clearly see & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },
// ON_COMMAND(id, OnFoo) is the same as
// ON_CONTROL(0, id, OnFoo) or ON_BN_CLICKED(0, id, OnFoo)But in VS2008, it goes a bit weird. There is no & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
static_cast (memberFxn) },
// ON_COMMAND(id, OnBar) is the same as
// ON_CONTROL(0, id, OnBar) or ON_BN_CLICKED(0, id, OnBar)Moreover, in spite of the fact that there is no & before memberFxn, each line below works perfectly. 1. ON_COMMAND(ID_APP_ABOUT, CSingleApp::OnAppAbout) // & 2. ON_COMMAND(ID_APP_ABOUT, &CSingleApp::OnAppAbout) // no & I tried to find why, and I was curious if it could be because of static_cast<> but it turned out that static_cast has nothing to do with it. So I am wondering why in VS2008 I have 2 choices where I put & or I don't have to put &.
It goes waaaay back to the original C language of the 1970's. In the first edition of "The C Programming Language",
Kernighan and Ritchie wrote:
... an identifier which is declared "function returning ...", when used except in the function-name position of a call, is converted to "pointer to function returning ...".
In the second edition, the wording has changed to
... and expression of type "function returning T," except when used as the operand of the & operator, is converted to "pointer to function returning T."
In other words, the & has always been optional. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
It goes waaaay back to the original C language of the 1970's. In the first edition of "The C Programming Language",
Kernighan and Ritchie wrote:
... an identifier which is declared "function returning ...", when used except in the function-name position of a call, is converted to "pointer to function returning ...".
In the second edition, the wording has changed to
... and expression of type "function returning T," except when used as the operand of the & operator, is converted to "pointer to function returning T."
In other words, the & has always been optional. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
First of all, Thanks you so much for answering my question. However, I think that case that you mentioned is about just "pointer to function."
Peter_in_2780 wrote:
the & has always been optional.
But when using "pointer to MEMBER function", the & is not optional, but necessary as you see below.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};int main(){
fpop pFunc;
pFunc = Test::Op1; // compile error!
//pFunc = &Test::Op1; // the & is essential.
return 0;
}I know that MFC's message pump consists of Pointer to member function, which needs the &. Could you explain why? Thanks.
-
First of all, Thanks you so much for answering my question. However, I think that case that you mentioned is about just "pointer to function."
Peter_in_2780 wrote:
the & has always been optional.
But when using "pointer to MEMBER function", the & is not optional, but necessary as you see below.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};int main(){
fpop pFunc;
pFunc = Test::Op1; // compile error!
//pFunc = &Test::Op1; // the & is essential.
return 0;
}I know that MFC's message pump consists of Pointer to member function, which needs the &. Could you explain why? Thanks.
Digging a bit deeper, I came across this[^] right here on CP. Seems VC6 and VC7 break the rules as you noticed... See just after the second code block below the heading "Member Function Pointers". Way too much information in that article for me! But if I ever need to go there... Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
Digging a bit deeper, I came across this[^] right here on CP. Seems VC6 and VC7 break the rules as you noticed... See just after the second code block below the heading "Member Function Pointers". Way too much information in that article for me! But if I ever need to go there... Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
That looks like a great article... Looks like I have some reading ahead of me... :)
-
That looks like a great article... Looks like I have some reading ahead of me... :)
It's a simple problem. At First, the massage map is implemented by an array with a structure. Secondly, the syntax error is actually a kind of warning. Third and finally, The massage map function starts with disabling the warning by a macro PTM_WARNING_DISABLE So, you may assign the function to a pointer without reference operator &. Here is an example, PTM_WARNING_DISABLE fpop pFunc[1] = {Test::Op1}; PTM_WARNING_RESTORE However, an interest problem occurs when you call the function with the function pointer. And the problem is all yours. :-)
modified on Wednesday, August 31, 2011 5:42 AM
-
It's a simple problem. At First, the massage map is implemented by an array with a structure. Secondly, the syntax error is actually a kind of warning. Third and finally, The massage map function starts with disabling the warning by a macro PTM_WARNING_DISABLE So, you may assign the function to a pointer without reference operator &. Here is an example, PTM_WARNING_DISABLE fpop pFunc[1] = {Test::Op1}; PTM_WARNING_RESTORE However, an interest problem occurs when you call the function with the function pointer. And the problem is all yours. :-)
modified on Wednesday, August 31, 2011 5:42 AM
did you mean to send this message to the OP? ...because I didn't ask the question...