Re: [boost] [review] Fusion review, finalization

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-12 18:52:33

Joel de Guzman wrote:
> Tobias Schwinger wrote:
> 
>>Joel de Guzman wrote:
>>
>>>Tobias Schwinger wrote:
> 
> 
>>5. BTW...
>>
>>   I found it surprising that "iter->second" didn't work in place of "(*iter).second" 
>>   (see lines 456, 485)...
> 
> 
> This is tough. operator-> is required to be a member function.

*hits hand against forehead* ...and cannot be a template because there are no arguments.

> Unfortunately, that would also mean that the type dereferenced
> should also be known at compile time. This will ultimately break
> the MPL requirement that an iterator pointing at the *end* should
> not be dereferenced-- that's what will happen by the very act of
> computing the operator->'s return type.
> 
> Nullary (non-templatable) member functions such as this and
> operator() with no args are such PITAs! 

Those arbitrary and irregular restrictions on operator 
overloading are in general!

> If I have a wish for C++0x,
> one would be to allow them to be templated non members. 

Absolutely. I guess, this part of the current standard 
annoys both C++ programmers and implementors...

> 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? 
 
> Eval::no_nullary has to search the expression tree! A compile-time
> expensive operation!
> 
> Unfortunately for Fusion iterators, I can't find a suitable workaround
> to enable operator-> return type deduction only when appropriate. 

There might be none ;-(...

> In general, an iterator does not know if it is at the end.

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

Regards,

Tobias