[range] Can iterator_range also model Random Access Range?
It seems that iterator_range can properly model any refinement of the Forward Range concept. Is that right? The reason I ask is that this is not very clear from the documentation, and I had to deduce this from both the iterator_range API and the Random Access Range concept definition. (See documentation at: range/reference/utilities/iterator_range.html) Thanks, Mostafa
On Tue, 03 Dec 2013 16:37:25 -0800, Mostafa <mostafa_working_away@yahoo.com> wrote:
It seems that iterator_range can properly model any refinement of the Forward Range concept. Is that right? The reason I ask is that this is not very clear from the documentation, and I had to deduce this from both the iterator_range API and the Random Access Range concept definition. (See documentation at: range/reference/utilities/iterator_range.html)
Does the same also apply to sub_range? Thanks, Mostafa
Yes, of course. The underlying iterator's just needs to be random access. regards -Thorsten
On Wed, 04 Dec 2013 01:26:10 -0800, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Yes, of course. The underlying iterator's just needs to be random access.
regards
-Thorsten
Unfortunately, and respectfully, that is not at all clear from either docs, please reread range/reference/utilities/iterator_range.html and range/reference/utilities/sub_range.html. The latter defers to the former, and all the former states about range concepts is: "The intention of the iterator_range class is to encapsulate two iterators so they fulfill the Forward Range concept". And, obviously, just because some type fulfills the Forward Range concept does not mean that it fulfills refinements thereof. Additionally, there is no indication in the iterator_range doc if the underlying iterator models refinements of the Forward Iterator concept, than its corresponding iterator_range class also models analogous refinements of the Forward Range concept. A statement along the lines of the last sentence added to the iterator_range doc would go a long way towards clarifying this, else one is left with being forced to deduce this fact. Mostafa
Unfortunately, and respectfully, that is not at all clear from either docs, please reread range/reference/utilities/iterator_range.html and range/reference/utilities/sub_range.html. The latter defers to the former, and all the former states about range concepts is: "The intention of the iterator_range class is to encapsulate two iterators so they fulfill the Forward Range concept". And, obviously, just because some type fulfills the Forward Range concept does not mean that it fulfills refinements thereof. Additionally, there is no indication in the iterator_range doc if the underlying iterator models refinements of the Forward Iterator concept, than its corresponding iterator_range class also models analogous refinements of the Forward Range concept. A statement along the lines of the last sentence added to the iterator_range doc would go a long way towards clarifying this, else one is left with being forced to deduce this fact.
I agree that the documentation is incomplete here. I would be happy to review and commit a documentation patch. Regards, Nate
On Mon, 09 Dec 2013 23:00:43 -0800, Nathan Ridge <zeratul976@hotmail.com> wrote:
Unfortunately, and respectfully, that is not at all clear from either docs, please reread range/reference/utilities/iterator_range.html and range/reference/utilities/sub_range.html. The latter defers to the former, and all the former states about range concepts is: "The intention of the iterator_range class is to encapsulate two iterators so they fulfill the Forward Range concept". And, obviously, just because some type fulfills the Forward Range concept does not mean that it fulfills refinements thereof. Additionally, there is no indication in the iterator_range doc if the underlying iterator models refinements of the Forward Iterator concept, than its corresponding iterator_range class also models analogous refinements of the Forward Range concept. A statement along the lines of the last sentence added to the iterator_range doc would go a long way towards clarifying this, else one is left with being forced to deduce this fact.
I agree that the documentation is incomplete here. I would be happy to review and commit a documentation patch.
I've created a pull request at GitHub.
Unfortunately, and respectfully, that is not at all clear from either docs, please reread range/reference/utilities/iterator_range.html and range/reference/utilities/sub_range.html. The latter defers to the former, and all the former states about range concepts is: "The intention of the iterator_range class is to encapsulate two iterators so they fulfill the Forward Range concept". And, obviously, just because some type fulfills the Forward Range concept does not mean that it fulfills refinements thereof. Additionally, there is no indication in the iterator_range doc if the underlying iterator models refinements of the Forward Iterator concept, than its corresponding iterator_range class also models analogous refinements of the Forward Range concept. A statement along the lines of the last sentence added to the iterator_range doc would go a long way towards clarifying this, else one is left with being forced to deduce this fact.
I agree that the documentation is incomplete here. I would be happy to review and commit a documentation patch.
I've created a pull request at GitHub.
Thanks! I reviewed the PR on GitHub. (Sorry for taking so long. The last time I committed a change to Boost.Range, Boost was still using SVN. I had some process-related catching up to do.) Regards, Nate
participants (3)
-
Mostafa -
Nathan Ridge -
Thorsten Ottosen