From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-15 16:55:50
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 Eval::no_nullary
>> // avoid calling apply_actor when this is true
>> , mpl::identity<detail::error_expecting_arguments>
>> , apply_actor<eval_type, basic_environment<> >
>> 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.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk