Though implementation problem

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.

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.

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 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.

This is where we differ and typically why my iterators won't work with STL.

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.

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.

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.

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.

What does (iter2 - iter1) mean, where iter1 and iter2 are of your iterator types?

Code:

			public boost::subtractable<CIteratorBaseTmpl, uint32_t>,
			public boost::subtractable<CIteratorBaseTmpl>

Or in other words:

Code:

CIteratorBaseTmpl operator - (CIteratorBaseTmpl, uint32_t);
CIteratorBaseTmpl operator - (CIteratorBaseTmpl, CIteratorBaseTmpl);

Where CIteratorBaseTmpl is:

Code:

#		define CIteratorBaseTmpl CIteratorBase<VecT, VecTraits, Base, BaseIterator, DerefType>

(Probably looking to reform that long loads of templates, but not until I get this stable and working.)

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?

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.

CIteratorBase& operator -= (const CIteratorBaseTmpl& vPos);

This operator is inherently nonsensical. Iterators are not indices. You don't get an iterator when you subtract two iterators.

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...

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.

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.

Why use this kind of "iterator" when you can use a size_type (or size_t) to represent the position (index)?

Originally Posted by CornedBee

This operator is inherently nonsensical. Iterators are not indices. You don't get an iterator when you subtract two iterators.

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.

Originally Posted by laserlight

Why use this kind of "iterator" when you can use a size_type (or size_t) to represent the position (index)?

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.

The const_iterator promises that as long as you use it, none will modify the memory it points to.

It makes no such promise. That would be quite impossible.
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.

Just confusion in thinking, that's all. I will change it to return distance instead and see how it works out.