Re: [gtkmm] TreeIter: const_iterator and reverse iterator
- From: Murray Cumming <murrayc murrayc com>
- To: Carl Nygard <cjnygard fast net>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [gtkmm] TreeIter: const_iterator and reverse iterator
- Date: Wed, 04 Feb 2004 13:26:43 +0100
On Tue, 2004-02-03 at 09:59, Carl Nygard wrote:
> On Mon, 2004-02-02 at 12:18, Murray Cumming wrote:
> > A TreeModel::const_iterator would be like a TreeModel::iterator (a
> > TreeIter) which returns a const TreeRow* instead of a TreeRow* from
> > operator*().
> >
> > So how could we implement this?
> > a) Derive the const_iterator from the iterator or vice-versa.
> > b) Make the iterator a template, which can use TreeRow or const TreeRow.
> >
> > But I'd also like to implement a reverse_iterator. That would be like a
> > normal iterator, but operator++() would go backwards instead of
> > forwards. And there would probably be a const reverse_iterator too.
> > Advice is welcome.
>
> If your container is simple, you might be able to define iterators using
> the templates in bits/stl_iterator.h
Yes, in fact I am still hopeful that I can implement the reverse
iterators with the regular reverse_iterator<> template.
> If you have to do anything complicated to keep track of element
> position, then you have to write your own. I've found that if you try
> to derive one from another, you get some bad interactions, or you run
> into const-ness problems, or template binding problems with stl
> algorithms.
That's a pity. I hoped that I could derived iterator from
const_iterator. I guess that I can't derived const_iterator from
iterator, because that would allow an implicit cast from const_iterator
to iterator, losing const.
> After doing this a few times, I've generally settled on going about it
> like so:
[snip useful example code. Thanks for that.]
> Writing the iterators isn't hard, but the sad part is that it seems best
> to duplicate the code, rather than trying to derive too much from other
> iterator types.
I have had that suspicion as well, though I'll try it to be sure.
Copy/Pasting code makes me feel unwell.
> I can't recall the specifics, but you start to see the
> problems with template resolution when using the stl algorithms.
>
> Aha, I remember now. You can't derive iterator from const_iterator and
> expect to reuse the operator+/+=/++/etc functions because they return
> const_iterators. So you wind up writing all the functions anyway, so
> you might as well be clearer writing each separately.
>
> Templatizing the iterator/const_iterator is of course a good option.
I also thought about that, but I'd like to avoid it because there is
quite a lot of implementation that I'd like to keep out of a public
header.
> My
> example was not templated, because it was iterating over compressed
> float data which required different return values for operator*() [float
> for const, proxy_object-with-operator=(float) for non-const]. YMMV
>
> Regards,
> Carl
Thanks again.
--
Murray Cumming
www.murrayc.com
murrayc murrayc com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]