Re: [gtkmm] A const_iterator for TreeModel?

[Carl Nygard <cjnygard fast net>]

On Sat, 2004-02-28 at 08:48, Murray Cumming wrote:
> On Tue, 2004-02-17 at 14:54, Carl Nygard wrote:
> > On Tue, 2004-02-17 at 13:40, murrayc murrayc com wrote:
> > > > Take a look at Item 26 in Scott Meyer's Effective STL.  He says that
> > > > there is an implicit conversion from iterator to const_iterator
> > > > --- but not the other way around!.
> > > 
> > > Interesting. I had tried that with std::list_iterator and const_iterator,
> > > without success. Could someone else try as well please.
> > > 
> > 
> > Works for me.  I tried something a bit more involved than rzeh.
> 
> 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.

template<typename _Tp, typename _Ref, typename _Ptr>
    struct _List_iterator : public _List_iterator_base
  {
    typedef _List_iterator<_Tp,_Tp&,_Tp*>             iterator;
    typedef _List_iterator<_Tp,const _Tp&,const _Tp*> const_iterator;
    // ... [snip] ...

    _List_iterator(const iterator& __x)
    : _List_iterator_base(__x._M_node)
    { }

    // ... 
};

template<typename _Tp, typename _Alloc = allocator<_Tp> >
    class list : protected _List_base<_Tp, _Alloc>
{
    // ...
    typedef _List_iterator<_Tp,_Tp&,_Tp*>                 iterator;
    typedef _List_iterator<_Tp,const _Tp&,const _Tp*>     const_iterator;
    // ...
};


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.

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

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.  

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.

Regards,
Carl