Tobias Schwinger wrote:
Joel de Guzman wrote:
Tobias Schwinger wrote:
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.
OK. Then I wouldn't need an "end iterator" for a full iteration and could ask the *one* iterator whether it's at the end, right?
To be precise, the issue is not really knowing we are at the end. In all cases, you really can't. For example, an iterator range's end iterator can not know it is the end. You have to compare it with the begin iterator to really know. The real issue is knowing if an iterator is dereferencable. And, for that, it is certainly possible to have an is_dereferencable<I> trait.
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.
Yeah. But for my vote: I'd rather live without 'operator->' if it costs me more template instantiations per iteration frame. Further it's probably even more consistent to enforce explicit dereferentiation, so runtime code is kept in sync with result computation code (we'd have to use result_of::deref there, anyway).
You have a point there. I'm guessing though that the impact is not that significant. After all, you'll, more often than not, dereference the iterator anyway. So, in effect, bringing op-> will mean eager evaluation at compile time of result_of::deref plus an eval_if plus is_dereferencable<I>. result_of::deref will be memoized when you actually do the deref. is_dereferencable<I> is cheap compared to phoenix's no_nullaries. Then again, all these wouldn't be needed if C++ allowed -> to be a non-member template!!! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net