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