Re: [libxml++] Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

[Stefan S. <se...@sy...>]

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
}

but rather

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
attributes.


> 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.


Stefan