"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Angus Leeming <angus.leeming@btopenworld.com> writes:
David Abrahams wrote:
In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/).
The iterator_adapter docs spell it "CategoryOrTraversal" too.
No, the spelling is as intended.
The naming of the implementation, and the (informal, so far?) proposal by you, Siek and Witt (sp?), is a bit misleading.
Well, it seems as though you were misled somewhere along the way.
A few comments/suggestions:
1. A group of concepts should be called either "group" or "category" (I think you stick to the former most, of not all, of the time) consistently in both proposal and implementation.
I have no idea what you're referring to. Maybe you should specifically point to text you think should be changed, and why.
2. Why is one concept group (i.e., one part of the dichotomy) called "category"
Because that's what the existing standard calls it.
and the other "traversal."
Because that's what it describes.
Potential confusion ahead... I propose "access" and "traversal,"
Existing category tags do not describe just access. They describe a combination of access and traversal, as you can see by reading http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
since I see no more of a "categorically" intrinsic property in one group than the other, i.e., labeling the access dimension as categorical is a bit unfair to the poor traversal dimension ;-)
It would be, but we're not doing that.
Furthermore, connected to (1), category is often used to denote a group of concepts, so I understand Angus' confusion.
I don't know what you're talking about again.
3. In the traversal group/category of concepts, they should either *all* include the lexeme "traversal" or *none*.
Probably a good idea. We made that change to the tags, but not to the concept names.
In fact, I propose to completely skip the "traversal" in the concept names. The only potential conceptual hurdle is the "access" in "random_access" (or RandomAccessIterator) that can be confused with the access-related group of concepts...
Bad idea, IMO. incrementable_tag, for example, shouldn't be reserved by an iterators library; it could apply to lots of things.
4. The access group of iterator concepts: what is so "iterative" about them? I.e., are they not general proxy concepts, with potential applications in smart pointers and other proxy situations?
...and your point is...? They were designed so that they could be used independently from traversal.
Comment (4) above is a bit whimsical, admittedly, and I do understand the benefit of sticking to Iterator in the discussions, to easier combine with existing notions and concepts in STL.
-- Dave Abrahams Boost Consulting www.boost-consulting.com