
I am writing some algorithms to operate on MPL sequences, and I would like to use some form of concept checking to ensure that the types passed in that are supposed to be iterators are, in fact, iterators. The MPL library doesn't seem to have is_XXX_iterator<T> checks, and I have run into some difficulties in determining how to write them. The MPL documents state that a random_access_iterator is a 'refinement' of a bidirectional_iterator which is a 'refinement' of a forward_iterator, but its not clear what refinement means in this context. I initially assumed that this meant that a random_access_iterator_tag was derived from a bidirectional_iterator_tag which was derived from a forward_iterator_tag. This does not appear to be the case, so the obvious test for an iterator (checking that the class contains a member named 'category' that is a type derived from the iterator tag of the least acceptable iterator) will not work. I am sure I could cobble together something that would work by examining the internals of the library, but I would far rather have some guidance on the correct way to see if an iterator matches a given iterator model, within the API of the library. Does anyone have any suggestions? -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com

Hi Stirling, At Sat, 30 Oct 2010 17:55:35 -0400, Stirling Westrup wrote:
I am writing some algorithms to operate on MPL sequences, and I would like to use some form of concept checking to ensure that the types passed in that are supposed to be iterators are, in fact, iterators.
The MPL library doesn't seem to have is_XXX_iterator<T> checks, and I have run into some difficulties in determining how to write them. The MPL documents state that a random_access_iterator is a 'refinement' of a bidirectional_iterator which is a 'refinement' of a forward_iterator, but its not clear what refinement means in this context.
http://www.generic-programming.org/about/intro/concepts.php#refinement
I initially assumed that this meant that a random_access_iterator_tag was derived from a bidirectional_iterator_tag which was derived from a forward_iterator_tag.
That's a useful trick if you're calling runtime functions, but it wouldn't be useful for MPL as written.
This does not appear to be the case, so the obvious test for an iterator (checking that the class contains a member named 'category' that is a type derived from the iterator tag of the least acceptable iterator) will not work.
I am sure I could cobble together something that would work by examining the internals of the library, but I would far rather have some guidance on the correct way to see if an iterator matches a given iterator model, within the API of the library.
Does anyone have any suggestions?
I'm not sure exactly how to help, because I can't quite tell where you're stuck, so let me ask a few questions: 0. Which iterator concept do you want to check for? 1. Do you understand the requirements of that concept? 2. Do you understand how to test if those requirements are met? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Sat, Oct 30, 2010 at 8:57 PM, David Abrahams
At Sat, 30 Oct 2010 17:55:35 -0400, Stirling Westrup wrote:
I am writing some algorithms to operate on MPL sequences, and I would like to use some form of concept checking to ensure that the types passed in that are supposed to be iterators are, in fact, iterators.
http://www.generic-programming.org/about/intro/concepts.php#refinement
Thanks. That answers one of my questions then.
I initially assumed that this meant that a random_access_iterator_tag was derived from a bidirectional_iterator_tag which was derived from a forward_iterator_tag.
That's a useful trick if you're calling runtime functions, but it wouldn't be useful for MPL as written.
I'm not so sure of that, but I'm willing to be convinced otherwise.
I'm not sure exactly how to help, because I can't quite tell where you're stuck, so let me ask a few questions:
0. Which iterator concept do you want to check for?
All of them. Right now I need to test for forward iterators but I have some algorithms planned that are likely to want random access iterators. I figure if I have to write one of the concept checks, I may as well write all three.
1. Do you understand the requirements of that concept?
This is the big kicker for me. As far as I can tell from the
documents, there are only three requirements, and two (for deref and
next) don't apply to past-the-end iterators.
Since I need
BOOST_MPL_ASSERT(( is_forward_iterator
2. Do you understand how to test if those requirements are met?
Well, I have never actually had to write a concept check before, as I've always been able to find an existing one to meet my needs, but I think I have a decent grasp of the theory. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com

At Sun, 31 Oct 2010 18:16:21 -0400, Stirling Westrup wrote:
This is the big kicker for me. As far as I can tell from the documents, there are only three requirements, and two (for deref and next) don't apply to past-the-end iterators.
Then, if I were you, I would actually be checking for valid pairs of iterators. If they're unequal, you can look for deref and next on the first iterator.
Since I need
BOOST_MPL_ASSERT(( is_forward_iterator
)) to succeed,
It looks like you're talking about a trait to distinguish iterator categories. Concept checking, as classically practiced, is about generating errors. I realize that you have a BOOST_MPL_ASSERT in that example, but if you actually require that the above code works, then you need to be able to detect the category without generating errors. So, which one are you after? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (2)
-
David Abrahams
-
Stirling Westrup