Re: [gtkmm] A const_iterator for TreeModel?

[Murray Cumming <murrayc murrayc com>]

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.

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

>  and the iterator argument
> is an iterator internal to the vector, so it can't be const.  Well,
> possibly it could.... maybe... perhaps.. but I doubt it.
> 
> If you're talking about vector<>::insert(iterator, InputIter first,
> InputIter last) function, the InputIter is a template arg, so it could
> be a const_iterator, and that makes sense.

Yes.

> The footnote says basically "because that's how SGI did it" and it
> didn't get reviewed in the original spec.  Off the top of my head, I
> have a few guesses.  

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.
 
> A) could be that there is no guarantee that an iterator can be converted
> to const_iterator in all cases.  Stream iterators come to mind.  
> 
> B) this would imply that you'd be forced to supply identical
> implementation for the equivalent functions (as you're seeing), and that
> could have been a maintenance tradeoff no one wanted to make.  
> 
> Bear in mind that "the top of my head" when viewed in Riemann space can
> be considered topologically equivalent to "out my ass", so take this
> with a grain of salt;)  But the stream iterators seem like they could be
> driving the design.

Thanks a lot for the help.

-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com