RE: [libxml++] node iterators

[Murray Cumming Comneon com]

> From: Christophe de VIENNE [mailto:cdevienne alphacent com] 
> Le Vendredi 23 Mai 2003 18:57, andy glew amd com a écrit :
> >
> > In other words, I am agreeing with Murray that it is a separate
> > class.
> 
> 
> Me too (that's what I'm saying in the part of the message you 
> didn't quote :-)
> 
> So I started implementing something this way. I have the 
> following classes :
> ChildrenList, ChildrenList::iterator and ChildrenList::const_iterator
> 
> The API is STL-like :
> 
> iterator       ChildrenList::begin();
> const_iterator ChildrenList::begin() const;
> iterator       ChildrenList::end();
> const_iterator ChildrenList::end() const;
> 
> on the different iterators we have operators ++(), ++(int), 
> ==(), !=(), *() 
> and ->().
> I plan to add rbegin() and rend() and ad-hoc iterators.
> 
> Node::get_children() returns a reference to a ChildrenList 
> which is an 
> attribute of Node initialised in constructor.

Sounds good. I will look at it some time to compare it to the gtkmm STL-like
stuff, which tries to implement as much of the STL-style interface as
possible in terms of just a few other methods, or overloads of the methods.

Maybe we also need
const Node::ChildrenList Node::get_children() const;

I don't think we need
const Node::ConstChildrenList Node::get_children() const;
instead, but I could be wrong.
 
> One problem I faced is the type return by iterator::operator*().
> I first wanted to return a Node &. It is, I think, more 
> logical, and avoid 
> writing things like (*iter)->do_something().
> However this change the use of dynamic_cast to 'test' the 
> type of node. If the 
> cast fail we have an exception instead of just returning a 
> null pointer.

That might not be too bad. People would tell us if they didn't like it. We
would probably want to catch them internally though.
 
> Moreover this will make a bit heavy the switching from a 
> version to another 
> (but this may be acceptable from a 1.0 to 2.0 version upgrade).

Yes, that kind of change is acceptable between major versions.

> So the question is :
> What do you expect as a return type for 
> Node::ChildrenList::iterator::operator*() ?
> 
> remark:
> One alternative I thought of is to have :
>   Node * operator*()
> and
>   Node * operator->()
> So we can both avoid complicating use of dynamic_cast and 
> writing stuffs like 
> (*iter)->do_something().
> But I don't think this is a very standard behavior and would 
> prefer not to do 
> that.

It sounds odd.