
I like these a lot. Could you add a few more comments? I'm not sure what you mean by "keeps track of wrap" or NOT. Maybe some information about what difference means. That is when iterator loops around behind the other one - does this make the difference negative? Is this what is meant by wrap? Ideally, I would like to see these zipped up along with a simple document and added to the vault. Robert Ramey Neal Becker wrote:
I use these regularly. Work for me.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Robert Ramey wrote:
I like these a lot. Could you add a few more comments?
I'm not sure what you mean by "keeps track of wrap" or NOT.
Maybe some information about what difference means. That is when iterator loops around behind the other one - does this make the difference negative? Is this what is meant by wrap?
Ideally, I would like to see these zipped up along with a simple document and added to the vault.
Robert Ramey
I have uploaded cycle_iterator.hpp, cycle_iterator2.hpp, cycle_iterator.txt, and Ring.H to vault under 'iterators'. Here is cycle_iterator.txt: There are 2 kinds of cyclic iterator adaptors here. cycle_iterator keeps track of an absolute position. Even though a dereference into the container will be treated modulo the size of the container, when comparing iterators we will keep track (with the wrap member) how many times the iterator 'wrapped around'. That is, we have the concept of a 'realposition' offset_t realposition () const { return position + wrap * size; } The effect is that the distance between two iterators can be greater than the size of the container. cycle_iterator2 has different semantics, it does not track this wraparound. One effect of this is you will need to be careful if you wish to access all the elements in the container, since the iterator pointing to the 'begin' and that pointing to the 'end' in typical STL usage may be the same. Ring2.H is a (not fully cleaned up) example of usage. A Ring is a vector-like structure (std::vector by default) whose iterators are cycle_iterator.

I'm not sure if I already asked in a private conversion, but even if I did, this the occasion to ask again : why not have an assignment operator for cycle_iterator? I think the base iterator could be replaced by that which is contained in super_t.

er wrote:
I'm not sure if I already asked in a private conversion, but even if I did, this the occasion to ask again : why not have an assignment operator for cycle_iterator? I think the base iterator could be replaced by that which is contained in super_t.
Would not the default compiler-generated assignment operator work?

Neal Becker wrote:
er wrote:
I'm not sure if I already asked in a private conversion, but even if I did, this the occasion to ask again : why not have an assignment operator for cycle_iterator? I think the base iterator could be replaced by that which is contained in super_t.
Would not the default compiler-generated assignment operator work?
Not if the iterator is default constructed and later assigned, at least the last time I checked. I've modified your file here that corrects this problem: https://svn.boost.org/svn/boost/sandbox/statistics/iterator/

AMDG er wrote:
Neal Becker wrote:
er wrote:
I'm not sure if I already asked in a private conversion, but even if I did, this the occasion to ask again : why not have an assignment operator for cycle_iterator? I think the base iterator could be replaced by that which is contained in super_t.
Would not the default compiler-generated assignment operator work?
Not if the iterator is default constructed and later assigned, at least the last time I checked. I've modified your file here that corrects this problem: https://svn.boost.org/svn/boost/sandbox/statistics/iterator/
What does the default constructor have to do with it? The templated assignment operator is not strictly needed because of the implicit conversion. Also, the enable_if you put on it is wrong. In Christ, Steven Watanabe

Steven Watanabe wrote:
AMDG
What does the default constructor have to do with it?
Also, the enable_if you put on it is wrong.
Since enable_if is wrong (no ::type), then I guess it is the other
change (accessing the base through super_t) which corrects the problem
below, right?
#include <vector>
#include

er wrote:
Steven Watanabe wrote:
AMDG
What does the default constructor have to do with it?
Also, the enable_if you put on it is wrong.
Since enable_if is wrong (no ::type), then I guess it is the other change (accessing the base through super_t) which corrects the problem below, right?
... Is there some problem you're trying to solve?

Neal Becker wrote:
er wrote:
Steven Watanabe wrote:
AMDG What does the default constructor have to do with it?
Also, the enable_if you put on it is wrong.
Since enable_if is wrong (no ::type), then I guess it is the other change (accessing the base through super_t) which corrects the problem below, right?
... Is there some problem you're trying to solve?
Replace "problem" by "error".

er wrote:
Neal Becker wrote:
er wrote:
Steven Watanabe wrote:
AMDG What does the default constructor have to do with it?
Also, the enable_if you put on it is wrong.
Since enable_if is wrong (no ::type), then I guess it is the other change (accessing the base through super_t) which corrects the problem below, right?
... Is there some problem you're trying to solve?
Replace "problem" by "error". Can you provide an example of use that shows the problem/error?

Can you provide an example of use that shows the problem/error?
Here's an excerpt from the example given in one of my previous replies
to this post:
typedef cycle_iterator

er wrote:
Can you provide an example of use that shows the problem/error?
Here's an excerpt from the example given in one of my previous replies to this post:
typedef cycle_iterator
it_; it_ it(boost::begin(vec),boost::end(vec),0); it_ it2; it2 = it;
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/debug/safe_iterator.h:162:
error: attempt to copy from a singular iterator.
Interesting. This example, which I think is equivalent to yours, compiles
fine with gcc-4.4.1:
(I'm afraid I don't know what the above error means)
#include "cycle_iterator.hpp"
#include <vector>
int main() {
std::vector<int> v;
typedef boost::cycle_iterator

Neal Becker wrote:
Interesting. This example, which I think is equivalent to yours, compiles fine with gcc-4.4.1:
It's a runtime error. i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/debug/safe_iterator.h:162: error: attempt to copy from a singular iterator. Objects involved in the operation: iterator "this" @ 0x0xbffff5f8 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPdN10__gnu_norm6vectorIdSaIdEEEEEN15__gnu_debug_def6vectorIdS6_EEEE (mutable iterator); state = singular; } iterator "other" @ 0x0xbffff62c { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPdN10__gnu_norm6vectorIdSaIdEEEEEN15__gnu_debug_def6vectorIdS6_EEEE (mutable iterator); state = singular; }
participants (4)
-
er
-
Neal Becker
-
Robert Ramey
-
Steven Watanabe