Re: [Boost-users] [mpl] Iterator Concept Checking? SOLVED + Recommendation.

Subject: Re: [Boost-users] [mpl] Iterator Concept Checking? SOLVED + Recommendation.
From: Stirling Westrup (swestrup_at_[hidden])
Date: 2010-11-03 23:03:30

On Wed, Nov 3, 2010 at 10:02 PM, David Abrahams <dave_at_[hidden]> wrote:
> At Tue, 2 Nov 2010 21:06:25 -0400,
> Stirling Westrup wrote:
>>
>> I have solved the problem I was working on, but as I'm not completely
>> happy with my solution, I thought I'd post it here and make a
>> recommendation for a small change to MPL that would have simplified my
>> work.

>> In fact, the individual iterator
>> categories are completely misleading as they state that there is a
>                                          ^^^^^^^^^^
>> member named 'category' that is convertible to the type of the tag.
>
> Who states?  Where?  Oh, after searching... you mean, e.g.,
> http://www.boost.org/doc/libs/1_44_0/libs/mpl/doc/refmanual/bidirectional-iterator.html
> right?

Correct.

>> It would seem that one should use iterator_category to determine if
>> something is an iterator or not,
>
> That wouldn't work for STL iterators; can you explain why you would
> expect it to work here?

Well, as in the code I included in the original post of this thread,
one usually wants to see what iterator concept is being modeled by a
particular type, to ensure that the code that makes use of the type
can rely on certain properties. Checking to see that something is an
iterator and then checking to see if it is a particular model of an
iterator seems to be a waste, as the only use of the first check is to
see if the second would succeed.

Why not just guarantee that the second would succeed? Its not hard to
do, but it should be provided as part of the standard MPL, not as an
add-on, as I did.

>>
>> The above works, but it relies upon me testing to see if there is an
>> embedded category member, which I suspect is going to get deprecated
>> by iterator_category<> just like all the other members were.
>
> I'm sorry, I don't understand what you're trying to say about
> deprecation.  Deprecation is a human activity; iterator_category<>
> can't deprecate anything.

Sorry if I was unclear. I meant that use of Iterator::category would
likely be deprecated in favour of using
iterator_category<Iterator>::type, just as Iterator::deref and
Iterator::next have been deprecated in favour of deref<Iterator>::type
and next<Iterator>::type, and for the same reason. The extra level of
indirection allows for greater flexibility in what sorts of types can
be MPL iterators.

>> It would be far preferable for me if there was an actual
>> non_iterator_tag and iterator_category<> were already defined for
>> all types, so it could both be used in a convenient manner, and so
>> that there was an obvious way to write a specialization in the case
>> that, for instance, one needed the type 'int' to be an iterator.

I should mention, at this point, that this is completely analogous to
how the sequence_tag<X> metafunction works, as it returns a valid
sequence tag for any sequence type, and returns non_sequence_tag for
any non-sequence. This is extremely useful, and I just want something
that works exactly the same for iterators.

>> In the very least, please update the documentation to mention the
>> actual relationships between the tags in the discussion about the
>> iterators, and to remove the incorrect 'convertible' description.
>
> Well, we have a problem, in that a BidirectionalIterator is-not-a
> ForwardIterator by MPL's requirements, even though the documentation
> claims it is a refinement.  So MPL's concepts are just broken, and we
> need to fix that.  Aleksey?

Yup.

-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com