Re: [libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance
- From: Stefan Seefeld <seefeld sympatico ca>
- To: libxmlplusplus-general lists sourceforge net
- Subject: Re: [libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance
- Date: Thu, 06 Feb 2003 14:05:02 -0500
Jonathan Wakely wrote:
If the interface conforms fully to the STL concept of a Sequence then it
can be documented as such, and users can know _exactly_ what to expect
and what not to expect in terms of complexity guarantees.
As I said in another mail, STL doesn't define its algorithms like
template <typename container>
void loop(const container &c)
for (container::iterator i = c.begin(); i != c.end(); ++i)
// do something
template <typename iterator>
void loop(iterator begin, iterator end)
for (begin; begin != end; ++begin)
// do something
which is much more flexible (as you don't necessarily want to iterate
over the whole range) and simple (precisely because the way you
construct the iterators, i.e. whether via 'begin()' or
'children_begin()' is unconstrained).
If you absolutely want to look at a node as a container, you'd need
to consider two containers: one for the children, one for the
Maybe the iterator should only be available from the Document object,
giving access to all children, not available on each Node.
Even then you'd want different iterator types: you can iterate in
different orders, you can iterate only over a restricted region,
such as direct children of a given node, or just over the attributes
of a given node.
I think this proves that it is really a bad idea to pass the container
directly to an iterating function, as lots of STL algos do. It's much
simpler to pass the first and one-past-last iterators.
] [Thread Prev