Re: [gtkmm] A const_iterator for TreeModel?

[Carl Nygard <cjnygard fast net>]

On Sun, 2004-02-29 at 09:39, Murray Cumming wrote:
> On Sat, 2004-02-28 at 13:24, Carl Nygard wrote:
> > On Sat, 2004-02-28 at 08:48, Murray Cumming wrote:
> > > Hmm, yes, when I checked again I found that we can covert
> > > std::list<int>::iterator to std::list<int>::const_iterator.
> > > 
> > > But I'm looking at the _List_Iterator in /usr/include/g++-3/stl_list.h,
> > > and I don't see what is making this possible. I'd expect to see either a
> > > templated operator=() method in the _List_iterator, or a separate
> > > operator=(const_iterator, iterator) function. I'd like to do whatever
> > > the STL iterators do.
> [snip]
> > If you note the typedef of list::const_iterator vs. list::iterator, they
> > only differ in the _Ref and _Ptr definitions.  So a list::const_iterator
> > still has a ctor(const iterator&).  That's how you get a const_iterator
> > from a normal iterator.
> 
> Thanks. Now I'm wondering how a const_iterator can be copied, because I
> only see the _List_Iterator(const iterator&) constructor, which means
> either
> 
> list::iterator(const list::iterator&)
> or
> list::const_iterator(const list::iterator&)
> 
> but I see no
> 
> list::const_iterator(const list::const_iterator&)
> 
> Any idea? It does work in a quick test - I just don't know how.

Neither _List_iterator_base nor _List_iterator define any type of copy
ctor.  Ultimately both are just POD structs, so the compiler provides
one.  The only member is the _List_node_base ptr, and that's a simple
copy.

> 
> > > By the way, I think this is the part of Effective STL that you are
> > > talking about:
> > > http://www.cuj.com/documents/s=8191/cuj0106smeyers/
> > > 
> > > I notice that he says that methods, such as vector<>insert() always take
> > > iterator, and never const_iterator, so const_iterator is not very
> > > useful, and can't be used with those methods. I don't know whey
> > > const_iterator is not used instead, and I don't know whether we should
> > > use const_iterator instead.
> > 
> > The obvious: vector<>::insert() isn't const,
> 
> Actually it's by value:
> 
> iterator insert(iterator __position) 
> 
> If it was not const then wouldn't we expect the iterator to be changed?
> I'm sure that it's not.

Um, thinking about list<> specifically, insert() inserts nodes before
the __position iterator.  Since it's a list, the __position node is
going to change it's previous ptr link, so it couldn't be a
const_iterator.  I.e. the node the iterator points to is going to be
changed, so the _Ptr and _Ref template parameters that govern return
values of the iterator can't be const.  Or else you have to const_cast<>
and nobody likes that.

[snip]
> 
> So, for now I will leave TreeModel as crippled as stl::list and co - I
> will just use iterator in the methods and never const_iterator. Maybe we
> can change that later. The const_iterator would still be as useful for
> TreeModel as it is for stl::list.
>  

The principle of least surprise is a good principle to follow.  I'd be
more concerned with how the TreeModel iterators interact with standard
algorithms than with TreeModel function signatures, I think.  For
example, could I pass to iterators to sort() and expect something
reasonable to happen?  I'm guessing not, so I'll amend my previous
statement to making sure the TreeModel iterators can't be used with
algorithms that don't/can't work.

Not that I'm trying to make more work for you;)


> Thanks a lot for the help.

No problem, I always enjoy interesting questions...

Regards,
Carl