On Wed, Nov 3, 2010 at 10:02 PM, David Abrahams <dave@boostpro.com> 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-it... 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