Stjepan Rajko wrote:
On 7/17/07, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Christian Holmquist wrote:
My question is how to disable the call operators with fewer arguments than specified by Sequence, generated by unfused_typed<F, Sequence>. Before the switch to boost::result_of one could specialize the result struct to only handle the expected Sequence type, thus disabling unwanted operators. I'm not familiar with boost::result_of to describe this however. ... I removed that kind of control over the overload sets of the Fusion functional adapters (you can't pass emptiness through result_of), but I'm not really happy about it.
<snip code>
Any ideas? Currently I think it might be best to re-add that mechanism for the 'unfused_*' adapters, either by checking nested 'result' of the target function for emptiness (exploiting SFINAE where applicable) or by introducing a special type (e.g. 'fusion::undefined_function'), that when returned from 'result_of' disables the overload...
Thoughts anyone?
Sure... like Christian, initially I was expecting that unfused_typed would give me only the overload with all of the types
I think I'll just change 'unfused_typed' to these semantics (with two overloads - for const-correctness ;-) ). Hopefully those changes will also keep MSVC 7.1 from ICEing for the non-const operator() (see workaround in the code)... <snip>
Although, if there is a need for specifying that a function should not be called a certain way, maybe it should have a more generic treatment, like boost::undefined_function for starts? Just in case someone needs to tell both fusion and something else to stay away, for the same function object.
Hmm... now that I think of it, I guess in something I was working on I implemented a "has_result_of" trait that checks for either existence of result_type, or the right result overload... > that might also work here, but I'm not sure how my has_result_of implementation fares, and whether it can be fixed to use result_of directly (i tried and failed for some reason) and also work when result_of is a typeof forwarder. So I don't know about whether this might also be an avenue.
There is a consistent, intermediate state in the CVS (about a week ago), that uses the nested 'result' directly (with 'result_of' protocol) and checks for emptiness. I actually considered keeping this version, documenting another concept (refinement of Polymorphic Function Object requiring nested 'result' that can be empty), but concluded that this approach feels wrong, because it can't work with 'result_of', relies on result type computation (which can be removed with the next language version) and it complicates the conceptual perspective of things. Reading your code (link in the follow-up post) it seems you're checking for a similar (though not identical, because of 'result_type') concept.
Well, that's my thoughts :-) Thanks for asking. In my code I'm using something like a unfused_typed_inherited which inherits the unfused function (because I need it to have both the original fused operator and the unfused operator). I think I showed it to you at some point, although I got rid of
that whole "unfusing the constructor as well" business.
Yep, I remember. Such a "function template emulator" is actually quite tempting to have - I'll eventually get back to it. Regards, Tobias