
Tobias Schwinger wrote:
Joel de Guzman wrote:
Tobias Schwinger wrote:
In Phoenix, I had to go through hoops just to disable_if the nullary operator(). Eager evaluation wreaks havoc! Look:
typename mpl::eval_if< typename Eval::no_nullary // avoid calling apply_actor when this is true , mpl::identity<detail::error_expecting_arguments> , apply_actor<eval_type, basic_environment<> > >::type operator()() const;
Interesting. Just curious: how would you mask "nullaries" whith a non-member template function?
You don't. It just works because templates are delayed. If operator()() can be a non-member, I would write that as: template <typename Actor> actor_result<typename Actor::eval_type, basic_environment<> > operator()(Actor const& actor);
Something different (that sentence just brought it back to my mind):
I noticd that fusion::pair<end>(begin) works quite well as a "compound iterator" but has a pretty uncool interface. A wrapper around it could give a useful utility...
'in' is of type fusion::pair<end>(pos), '==>' denotes interface transformation provided by an imaginary wrapper
*in.second ==> *in equal_to<typename In::first_type, typename In::second_type> ==> eoi<In>
Since this thing knows when it's at the end, it could (BTW) even have an operator-> that disappears in this case...
I'd refrain from commenting right now because I realized I might have been wrong. I think now that Dave is correct that we can detect an iterator pointing nowhere and simply return void_ or something like I did above for Phoenix. Thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net