RE: [libxml++] node iterators

[<Mur...@Co...>]

> From: Christophe de VIENNE [mailto:cde...@al...]=20
> Le Vendredi 23 Mai 2003 18:57, and...@am... a =E9crit :
> >
> > In other words, I am agreeing with Murray that it is a separate
> > class.
>=20
>=20
> Me too (that's what I'm saying in the part of the message you=20
> didn't quote :-)
>=20
> So I started implementing something this way. I have the=20
> following classes :
> ChildrenList, ChildrenList::iterator and ChildrenList::const_iterator
>=20
> The API is STL-like :
>=20
> iterator       ChildrenList::begin();
> const_iterator ChildrenList::begin() const;
> iterator       ChildrenList::end();
> const_iterator ChildrenList::end() const;
>=20
> on the different iterators we have operators ++(), ++(int),=20
> =3D=3D(), !=3D(), *()=20
> and ->().
> I plan to add rbegin() and rend() and ad-hoc iterators.
>=20
> Node::get_children() returns a reference to a ChildrenList=20
> which is an=20
> 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.
=20
> One problem I faced is the type return by iterator::operator*().
> I first wanted to return a Node &. It is, I think, more=20
> logical, and avoid=20
> writing things like (*iter)->do_something().
> However this change the use of dynamic_cast to 'test' the=20
> type of node. If the=20
> cast fail we have an exception instead of just returning a=20
> 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.
=20
> Moreover this will make a bit heavy the switching from a=20
> version to another=20
> (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=20
> Node::ChildrenList::iterator::operator*() ?
>=20
> 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=20
> writing stuffs like=20
> (*iter)->do_something().
> But I don't think this is a very standard behavior and would=20
> prefer not to do=20
> that.

It sounds odd.