libxmlplusplus-general

Re: [libxml++] node iterators

[Jonathan W. <co...@co...>]

On Fri, May 23, 2003 at 10:42:37AM +0200, Christophe de VIENNE wrote:

> > http://sourceforge.net/tracker/index.php?func=detail&aid=708826&group_id=12
> >9 99&atid=312999
> 
> About this one I don't know what to do.
> Could somebody using on_get_entity() callback in SaxParser tell me what he 
> thinks about it ?

I've not been able to finish this work. I don't need it for work I'm
doing in my day job, so haven't had time to work on it.

I came to the conclusion that entities and SAX are a complete nightmare
and ran away with my tail between my legs.

I would still recommend removing the on_get_entity() callback until
someone figures out how to do it properly.

> What do you think about this one ? If you're OK I'll implement this 
> additionnal protected constructor I'm speaking about.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=690193&group_id=12999&atid=312999

I did do most of the work to make the ctor take a bitset specifying the
callbacks to use, I could dig it out this weekend if you haven't done it
already.

jon


-- 
"What contemptible scoundrel stole the cork from my lunch?"
	- W.C. Fields

RE: [libxml++] node iterators

[<and...@am...>]

> For begin(), just a mistake of me. What I wanted to write is :
> 
>    for( xmlpp::NodeIterator i = node.children_begin(),

How different is this from

    for( xmlpp::NodeIterator i = node.children().begin(),

Or

    for( xmlpp::NodeSet::iterator i = node.get_children().begin(),

?

What you are trying to avoid is iterating, constructing the NodeSet,
and then reiterating.

I suggest the way to do that is to make node.get_children()
(or node.children(), or...) return, not an STL set(node),.


In other words, I am agreeing with Murray that it is a separate
class.  Or, rather, a separate API, that might just delegate
to the node class.

Re: [libxml++] node iterators

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


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), =3D=3D(), !=3D(=
), *()=20
and ->().
I plan to add rbegin() and rend() and ad-hoc iterators.

Node::get_children() returns a reference to a ChildrenList which is an=20
attribute of Node initialised in constructor.


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=
=20
writing things like (*iter)->do_something().
However this change the use of dynamic_cast to 'test' the type of node. If =
the=20
cast fail we have an exception instead of just returning a null pointer.

Moreover this will make a bit heavy the switching from a version to another=
=20
(but this may be acceptable from a 1.0 to 2.0 version upgrade).

So the question is :
What do you expect as a return type for=20
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 li=
ke=20
(*iter)->do_something().
But I don't think this is a very standard behavior and would prefer not to =
do=20
that.




Regards,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+0gs0B+sU3TyOQjARAlh8AJ0fw41qtK1QtMxB1sY0mmjmVvxAegCg4SgB
PYyxAMYlOId6SQiJz/aSl5Q=3D
=3DuUIR
=2D----END PGP SIGNATURE-----

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.

RE: [libxml++] node iterators

[<and...@am...>]

> 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.
> 
> So the question is :
> What do you expect as a return type for 
> Node::ChildrenList::iterator::operator*() ?

I always use Node& for such code.  (In more detail,
I use a T& if the value is copied into the container,
and if modifying the value in the container does not
affect the value copied from; I use T* if modifying
the value 

To get a non-trapping dynamic cast, the user can always
take the address:

	dynamic_cast<Special_Node*>(&(*iter))