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

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-13 07:28:07

David Abrahams wrote:
> Joel de Guzman <joel_at_[hidden]> writes:
> 
>> 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.
>> 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.
> 
> I don't buy that argument.  The past-the-end-iterator has a different
> type from all the others, and since it's not dereferenceable anyway,
> it doesn't need to have an operator->.  Furthermore, 

Sure, all iterators have different types, but there's nothing special
with past-the-end-iterator. For example, an iterator adapter treats
all its held iterators equally.

>> Unfortunately for Fusion iterators, I can't find a suitable workaround
>> to enable operator-> return type deduction only when appropriate. In
>> general, an iterator does not know if it is at the end.
> 
> That part seems strange to me.  It certainly could know whether it's
> at the end, I think.

Thinking about it some more, you may be right. Maybe I can use
the disable_if technique. At the very least, I'll need a
is_dereferencable<I> metafunction so I can also disable ->
on adapted iterators.

I'll see if I can come up with something.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net