Opened 16 years ago
Closed 16 years ago
#303 closed defect (fixed)
Cannot convert VectorMutable::iterator to VectorBase::const_iterator
Reported by: | Peter | Owned by: | Peter |
---|---|---|---|
Priority: | major | Milestone: | yat 0.4 |
Component: | utility | Version: | trunk |
Keywords: | Cc: |
Description (last modified by )
needed for ticket:306
Typically you want to allow this conversion implicitly so e.g. iterator can be compared with const_iterators. For that reason Iterator provides a conversion operator from Iterator<reference, container> to Iterator<const reference, const container>. The problem is that const_iterator is storing a const VectorBase*
not a const VectorMutable*
. I have tried in several ways, but yet no cigars...
There is a test in test/vector_test.cc for this thing that for the moment is silenced; look for const conversion doesn't work for new vector structure
I place this in 0.4 because I think it should be solved asap, but if a solution is hard to find of course we have to postpone this issue.
Change History (4)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
I forgot to say. We need better names. Having two iterator classes it makes no sense to call one of them Iterator. Suggestions?
comment:3 Changed 16 years ago by
Description: | modified (diff) |
---|
I think I got an idea for how to solve this. We will need a new iterator class.
Current Iterator stores a container and and an index telling which element the iterator points to. Instead we could use a more classic approach: having a pointer member variable (
double*
) and an additional size_t stride to work out the arithmetic.The pointer type (and perhaps also the size_t) should be templatized to be generic but most of all to allow constness.
On the plus side is that this solution will solve another issue about the current iterator. Comparisons of iterators are not defined if the belong to different containers. This could be confusing when dealing with views that are pointing to the same underlying data. Also, this new iterator class could be used for matrix::iterator (see e.g. ticket:267).
Also we should check in current Iterator that we never get behavior like a>b and b>a. That kind of inconsistence is only bad and should be easy to avoid.