Re: [libcvd-members] libcvd/cvd image.h [subimage2]

[Gerhard Reitmayr]

Edward Rosten wrote:
>> Hi Ed,
>>
>> I am following your iterator work with interest. did you think about
>> deriving from
>> stl::iterator defined in <iterator> ? this would probably define all
>> your types to make them work properly with stl.
> 
> According to my Stroustrup book, std::iterator provided the 5 typedefs
> I've now put in to iterator. I could make ConstSubImageIterator derive
> from std::iterator, but I'd still have to override the pointer and
> reference in SubImageIterator to be non-const types.
> 
> Is there additional benefit, or is it just a helper class?

I don't think so. I guess defining the same things is enough.

> What do  you think of the iterator design? I'm not 100% sure about it,
> since it has a const_cast<>(). It shouldn't invoke undefined behaviour,
> since there is no way to access the pointer as non-const, and it allows
> non-const iterators to degenerate to const ones (just like the normal
> const keyword), and all comparisons keep on working.
> 

how does a typical stl implementation solve this? just implementing all
the different comparison operators and constructors?

> Also, what about .end() versus .fastend()? It makes the common case
> cheap, but not for STL algorithms, unfortunately.

well, I am amazed that the fastend version is so much faster. Of course,
it is annoying that the user has to know about this optimisation and use
it on purpose.

I also had a similar problem that stl only takes the same iterators, it
is annoying. the solution could be to make the *End type a real iterator
and just pass both begin and end to stl functions. so you could have a
fastbegin() than as well and simply use fastbegin/fastend for stl.

I do something similar for a member_iterator: check out tag/fn.h it
contains a member_iterator that accesses the member of a struct/class
stored in containers. If algorithm functions are written to take
iterators, then this allows them to work both on simple types or members
of more complex types.

Gerhard

> 
> -Ed


-- 
Gerhard Reitmayr
MIL, Engineering Department, Cambridge University
http://www.eng.cam.ac.uk/~gr281/