RE: [libxml++] node iterators
- From: Murray Cumming Comneon com
- To: libxmlplusplus-general lists sourceforge net
- Subject: RE: [libxml++] node iterators
- Date: Mon, 26 May 2003 14:47:38 +0200
> 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]