Iterators are a generalisation of pointers. Pointers are a subset of the set of random access iterators.An iterator is not a pointer, but the STL seems to treat them like it.
Iterators are a generalisation of pointers. Pointers are a subset of the set of random access iterators.An iterator is not a pointer, but the STL seems to treat them like it.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
This isn't how my implementation treats it. An iterator is not a pointer and will never be.
An iterator is similar to a pointer in the way that it can be used to walk from a starting location towards an end.
This is where we differ and typically why my iterators won't work with STL.
I think that you are confusing the superset with the subset. An iterator is not a pointer. A pointer is an iterator. In particular, a pointer is a random access iterator.An iterator is not a pointer and will never be.
An iterator is similar to a pointer in the way that it can be used to walk from a starting location towards an end.
I suppose you do not have to provide random access iterator semantics. You can say: my iterators are input/output/forward/reverse/bidirectional iterators. Yes, operator- is provided, but it has nothing to do with the operator- used with random access iterators.This is where we differ and typically why my iterators won't work with STL.
It may not be very nice and may be a rather error prone for those who assume that it is a random access iterator, but it can be done.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Sigh... So many choices.
Should non-const - const iterator be possible? Returning a non-const iterator from a const iterator is probably impossible, but returning an int, or the distance between them is not a pretty option to me.
But then again, in order to use and modify the data, it still needs to create another iterator from this int, so in that sense, there's nothing wrong with letting operator - return an int.
But then again, this blurs the borders between a const_iterator and iterator. The const_iterator promises that as long as you use it, none will modify the memory it points to. So extracting a distance between a const and non-const and then assigning it to a non-const seems like it's a workaround to this problem. In effect, the const_iterator seems like it isn't doing its job properly...
I'm getting lost in the const waters here... I don't know what to assume or take stance to.
What does (iter2 - iter1) mean, where iter1 and iter2 are of your iterator types?Should non-const - const iterator be possible? Returning a non-const iterator from a const iterator is probably impossible, but returning an int, or the distance between them is not a pretty option to me.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Or in other words:Code:public boost::subtractable<CIteratorBaseTmpl, uint32_t>, public boost::subtractable<CIteratorBaseTmpl>
Where CIteratorBaseTmpl is:Code:CIteratorBaseTmpl operator - (CIteratorBaseTmpl, uint32_t); CIteratorBaseTmpl operator - (CIteratorBaseTmpl, CIteratorBaseTmpl);
(Probably looking to reform that long loads of templates, but not until I get this stable and working.)Code:# define CIteratorBaseTmpl CIteratorBase<VecT, VecTraits, Base, BaseIterator, DerefType>
So it returns another iterator of same type with the new addr (original - other).
Confusion trail:
Code:CStringEx t = "blablabla"; CStringEx::iterator it1 = t.begin(); CStringEx::const_iterator it2 = t.const_begin(); CStringEx::iterator t3 = it - it2; // IMPOSSIBLE? (CASTS AWAY CONST) (TWO DIFFERENT TYPES)Code:CStringEx t = "blablabla"; CStringEx::iterator it1 = t.begin(); CStringEx::const_iterator it2 = t.const_begin(); int32_t t3 = it - it2; CStringEx::iterator it4 = t.begin() + t3; // WORKAROUND AROUND CONST?Code:CStringEx t = "blablabla"; CStringEx::iterator it1 = t.begin(); CStringEx::const_iterator it2 = t.const_begin(); int32_t t3 = it - it2; CStringEx::iterator it4 = t.begin() + t3; // CONST (T2) NOT DOING ITS JOB?
You could answer this please: what does (iter2 - iter1) mean, where iter1 and iter2 are of your iterator types?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Alright, it means you get a new iterator at the position (iter2 - iter1). It's the same sense as pointers, but it would be wrapped in an iterator container.
Code:CStringEx t = "1234"; CStringEx::const_iterator it1 = t.const_begin() + 3; CStringEx::const_iterator it2 = t.const_begin() + 2; CStringEx::const_iterator it3 = t2 - t1; cout << *it1; // 4 cout << *it2; // 3 cout << *it3; // 1
But pointer1-pointer2 does not give a pointer, it gives the distance between the pointers.
You're treating your iterators as array indexes.
Yes, the idea behind the iterator is that it represents a position within a container or object.
So if iterator 1 is at position 5, and iterator 2 is at position 3, then you might want to get something at position 2, so you subtract the iterators and thus get (5- 3) = 2, position 2. But all positions in the object is represented as iterators, so instead of the integer 2, you get the iterator at position 2.
Like, don't break the line. All ways seem to have complications, as listed above.
This operator is inherently nonsensical. Iterators are not indices. You don't get an iterator when you subtract two iterators.CIteratorBase& operator -= (const CIteratorBaseTmpl& vPos);
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
The const_iterator is doing its job properly. You cannot use it to modify any object in the range. You can use it to get a distance, and then use this distance with an iterator that can modify the range, but that's not a problem since in the context of the other iterator, the objects in the range are non-const.But then again, this blurs the borders between a const_iterator and iterator. The const_iterator promises that as long as you use it, none will modify the memory it points to. So extracting a distance between a const and non-const and then assigning it to a non-const seems like it's a workaround to this problem. In effect, the const_iterator seems like it isn't doing its job properly...
Why use this kind of "iterator" when you can use a size_type (or size_t) to represent the position (index)?Yes, the idea behind the iterator is that it represents a position within a container or object.
So if iterator 1 is at position 5, and iterator 2 is at position 3, then you might want to get something at position 2, so you subtract the iterators and thus get (5- 3) = 2, position 2. But all positions in the object is represented as iterators, so instead of the integer 2, you get the iterator at position 2.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Well, we do not think alike. But even if it were to return int32_t, what about the promise of const? What should const_iterator allow and what should it not? It's constant, which means it musn't allow the data to be modified. All of the member are constant.
If it returns an integer, then it allows for workaround what the const. But... if the object you call begin() or const_begin() from isn't const, I suppose that's OK, since you can ask the object which owns the iterator to return a non-const iterator and allow you to modify its data.
The idea is that an index is not an integer. 1 or 5 may not be valid indexes. Only an iterator is a valid index. That was the idea anyway.
It makes no such promise. That would be quite impossible.The const_iterator promises that as long as you use it, none will modify the memory it points to.
The only thing it promises is that no one can modify the element it points to through this particular iterator, the same as a pointer-to-const.
I don't see where your problem is.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law