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