Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-01-23 21:06:01

Jeremy wrote:

> Dave Abrahams writes:
> > Hi! Yes, I did take a look at the example. It sure is a _lot_ of code! The
> > question occurs to me whether I'd rather just write out the search
> > explicitly. Don't mean to be difficult, here ;)
> By a lot of code, are you refering to the just the copy visitor,
> or the whole example? There's a lot of other stuff in the example,
> especially with regard to setting up the adjacency-list graph
> type that will be simpler with the final ggcl version
> (Rich Lee is working on that as I type this).
> If you're just refering to the copy visitor, I don't see how
> it could be any smaller... just a class with a couple constructors
> and one global function, the overload of process().

Oh, sorry: it wasn't clear to me that the other parts would be supplied by
the library. In that case, I am more than happy with the example (except for
the using-directives!)

Now, in light of my abs/swap conversation, it concerns me that the graph
library is relying on Koenig lookup to find the process and discover
functions for a visitor.

It concerns me even more that the idiom for making a visitor involves
remembering to call a base class' process function (and using a
static_cast)! Can't we do something about that?

I'd like to be able to write something like this:

 template <class NewGraph, class Base = null_visitor>
 struct copy_visitor : public visitor<NewGraph, Base> {
   copy_visitor(NewGraph& graph) : g(graph) { }
   copy_visitor(NewGraph& graph, const Base& b) : g(graph),
        visitor<NewGraph, Base>(b) { }

   NewGraph& g;

 template <class NewGraph, class Base, class Edge, class Graph, class Bag>
 bool local_process(copy_visitor<NewGraph,Base>& vis, Edge e,
                    Graph& g, Bag& b)
   add_edge(vis.g, source(e,g), target(e,g));
   return true;

...but of course I don't see how to arrange it ;)


Boost list run by bdawes at, gregod at, cpdaniel at, john at