David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Tobias Schwinger wrote:
Joel de Guzman 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
Tobias Schwinger wrote: 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