RE: [boost] Re: Bizarre Lambda bind() problem with Base class types

-----Original Message----- Brian Braatz wrote:
With the following code, If you UNCOMMENT the "// public : Base"
line,
you get compiler errors (????)
I have tested this with MS VC 7.1 against both 1.31 and 1.32 versions of boost with the same results.
Any idea why this is happening? (full sample code I wrote is attached) [snip] std::string ReturnAString(); [snip] bind(Base::ReturnAString,_1);
[ Reece Wrote] This is the problem. Try: bind(Base::ReturnAString); or: bind(&Base::ReturnAString,this);
[Brian Braatz] THANK YOU BOTH REECE AND DANIEL :) (!!!!!!!!!!!!!!!) That fixed it. What is STRANGE is that "sometimes" bind(Base::ReturnAString) works ironically, I have about 40 calls that use that syntax that work just fine. I noticed in the docs, when you have a inline functor, the docs use
bind(Base::ReturnAString);
But when you have something that was not inline (??) you use:
bind(&Base::ReturnAString);
I was never clear on when you and when you do NOT use the "&" with the bind() syntax..... I will convert everything in my "real code" to using the & always. Question: Does anyone know when you should and should not use the & in a bind call? Or is this is compile time checking hole that exists due to the mechanisms bind relies upon? OR Am I a complete idiot? (I find it important to always hold open this option as a possibility in everything)

Brian Braatz wrote:
What is STRANGE is that "sometimes" bind(Base::ReturnAString) works
ironically, I have about 40 calls that use that syntax that work just fine.
AFAIK, being allowed to omit the '&' is a non-standard compiler extension. And one which has issues, as you just found out yourself :) Just use '&' consistently to retrieve (member-)function-pointers. Regards, Daniel

Brian Braatz wrote:
Question: Does anyone know when you should and should not use the & in a bind call?
The & is optional in front of ordinary functions, but required in front of member functions. This is how C++ works; functions are implicitly convertible to function pointers, but member functions need their address taken explicitly to form a pointer to member.
participants (3)
-
Brian Braatz
-
Daniel Frey
-
Peter Dimov