Re: [boost] Another iterator_adaptor example (was Re: Help with iterator helpers)

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-02-01 16:30:12

Hi Graham,

The Node that you are dealing with looks quite similar in flavor to the
LEDA interface for graph nodes that I adapted using the iterator adaptor
library. You can take a look at how the LEDA adaptors are implemented in
the header boost/graph/leda_graph.hpp. Also, I explain how that header is
implemented in the BGL book, Section 10.3. For another example, see
boost/graph/stanford_graph.hpp which adapts Stanford GraphBase nodes also
using iterator adaptors.

The LEDA-BGL example doesn't show how to do the constness... but once
you've got the basic thing implemented, I'd be willing to take a look at
the code tell you how to get the constness right.

Cheers,
Jeremy

On Fri, 1 Feb 2002 graham.shanks_at_[hidden] wrote:

graham> Without wishing to gainsay the development of the Cyclic Iterator
graham> Adaptor in this thread I think that this is missing an important
graham> point. All the examples in the documentation of the iterator
graham> adaptor library show adapators of iterators (excluding the
graham> existing counting_iterator example which as Dave says may not be
graham> that useful). The Cyclic Iterator Adapator (although good and
graham> useful in its own right) is just another example of adapting an
graham> existing iterator. IMHO what is missing from the documentation is
graham> an example of how to use the iterator adaptor library to transform
graham> a base type which is *not* an iterator into a standard conforming
graham> iterator .
graham>
graham> One of the things that many of us find ourselves having to do is
graham> to create an iterator for a class from a third party library,
graham> which provides the functionality required to implements iterators
graham> but not the iterators themselves. The major constraint is that we
graham> cannot change the interface of the class itself and do not even
graham> have access to the implementation of the class (which is contained
graham> within the object library).
graham>
graham> For instance consider the following class, which defines a tree of
graham> Nodes (for those who are interested this is a subset of the XML
graham> DOM interface, simplified to remove details not germain to this
graham> discussion)
graham>
graham>
graham> class Node
graham> {
graham> public:
graham>     Node();
graham>     Node(const char* const Name);
graham>     ~Node();
graham>
graham>     Node&  operator=(const Node &other);
graham>
graham>     std::string getNodeName() const;
graham>
graham>     Node  getFirstChild() const;
graham>
graham>     Node  getNextSibling() const;
graham>     Node  getPreviousSibling() const;
graham>
graham>     Node  appendChild(const Node &newChild);
graham>
graham>     bool  operator==(const Node &other) const;
graham>
graham> private:
graham>     class Implementation;
graham>     Implementation* pImplementation;
graham> };
graham>
graham> If I tell you that past-the-end can be tested by comparing to a
graham> default constructed Node, then I believe I'm right in saying that
graham> this has everything we need to create a bi-directional iterator
graham> for this class.
graham>
graham> Having done this once (the hard way, i.e without boost ) I am now
graham> looking to simplify this using iterator adaptors (after all the
graham> documentation says that it can be done and Dave reiterated this
graham> earlier in this thread).
graham>
graham> I return for some guidance from boosters I would be prepared to
graham> develop this as an example for inclusion in the documentation.
graham> My idea on how to do this is to provide a wrapper class
graham>
graham> class NodeWrap
graham> {
graham> public:
graham>     NodeWrap(Node& Node);
graham>
graham>     typedef boost::iterator_adaptor<???> iterator;
graham>
graham>     iterator begin();
graham>     iterator end();
graham>
graham> };
graham>
graham> Is this the correct way to go? How can I provide a const_iterator?
graham>
graham>
graham> Graham Shanks
graham>
graham>
graham>
graham> Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscribe_at_[hidden]>
graham>
graham> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
graham>
graham>

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek_at_[hidden]
 C++ Booster (http://www.boost.org)   office phone: [phone]
----------------------------------------------------------------------