Peter Dimov writes:
John Maddock wrote:
I actually consider this to be a vital usability feature. It would be an unpleasant surprise if it's not going to make it into comforming TR1 implementations. Or did I misunderstand your earlier comment?
I don't know if it's possible to support this, and to support the named-return-type syntax as well.
It's possible with some enable_if tricks. One needs to eliminate the R/F overload when F is a function pointer that returns R and is covered by one of the additional overloads.
I also don't see anything in the TR1 text that requires this to be supported... Peter?
It's not required in TR1. It is up to the implementation to make bind "just do the right thing" in such situations: overloaded functions where it's possible to disambiguate, nonstandard calling conventions, extern "C", nonstandard function object extensions.
Thanks for the clarification! IMO this list is worth putting into our TR1 bind docs, so that users have more chances to make an educated choice between "native" and Boost bind implementation. -- Aleksey Gurtovoy MetaCommunications Engineering