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

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-15 20:20:53

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