On 08/28/2011 04:06 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Sat, Aug 27, 2011 at 10:00 PM, Michael Caisse< boost@objectmodelingdesigns.com> wrote:
On 08/27/2011 04:20 PM, Jeffrey Lee Hellrung, Jr. wrote:
<snip>
in a compiler error over "SFINAE-disabling" them? (Other than compile time considerations and minimizing complexity.)
- Jeff
Hi Jeff -
I might be confused. I thought we were talking about the bound functor allowing a different number of arguments than the function that it is bound to. For example, more arguments like this:
<snip>
There is no error here. Have I missed the point?
As far as I understood it, yes. As I understood Eric's proposal, "bind( &log, _2, _1 )( timestamp, source, lat long, message )" would still compile fine, but "bind(&log, _2, _1 )( 0.0, (void*)(0) )" (for example) would result in a compiler error *at the call site* due to operator() overloads within boost::bind function objects (whatever those implementation objects are) being SFINAE-disabled for any argument binding that results in an "invalid invocation of the bound function". This behavior requires something like Boost.Proto's can_be_called (I may have the precise name wrong here...) machinery to implement. This buys one the ability to likewise use function object types returned by boost::bind in the same can_be_called machinery to enable compile-time introspection of *that* type. In the context of this thread, this allows one to decide when an argument passed to a curried function triggers the underlying function to be evaluated.
HTH,
- Jeff _______________________________________________
Thanks Jeff. I guess I wasn't following close enough (o; -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com