Boost logo

Boost :

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
>> 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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at