1.1 --- a/doc/gwrappers.dox Mon May 02 05:49:33 2005 +0000
1.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
1.3 @@ -1,80 +0,0 @@
1.4 -/**
1.5 - @defgroup gwrappers Wrapper Classes for Graphs
1.6 - \brief This group contains several wrapper classes for graphs
1.7 - @ingroup graphs
1.8 -
1.9 - The main parts of LEMON are the different graph structures,
1.10 - generic graph algorithms, graph concepts which couple these, and
1.11 - graph wrappers. While the previous notions are more or less clear, the
1.12 - latter one needs further explanation.
1.13 - Graph wrappers are graph classes which serve for considering graph
1.14 - structures in different ways.
1.15 -
1.16 - A short example makes this much
1.17 - clearer.
1.18 - Suppose that we have an instance \c g of a directed graph
1.19 - type say ListGraph and an algorithm
1.20 - \code template<typename Graph> int algorithm(const Graph&); \endcode
1.21 - is needed to run on the reversed oriented graph.
1.22 - It may be expensive (in time or in memory usage) to copy
1.23 - \c g with the reversed orientation.
1.24 - In this case, a wrapper class is used, which
1.25 - (according to LEMON graph concepts) works as a graph.
1.26 - The wrapper uses
1.27 - the original graph structure and graph operations when methods of the
1.28 - reversed oriented graph are called.
1.29 - This means that the wrapper have minor memory usage,
1.30 - and do not perform sophisticated algorithmic actions.
1.31 - The purpose of it is to give a tool for the cases when
1.32 - a graph have to be used in a specific alteration.
1.33 - If this alteration is obtained by a usual construction
1.34 - like filtering the edge-set or considering a new orientation, then
1.35 - a wrapper is worthwhile to use.
1.36 - To come back to the reversed oriented graph, in this situation
1.37 - \code template<typename Graph> class RevGraphWrapper; \endcode
1.38 - template class can be used.
1.39 - The code looks as follows
1.40 - \code
1.41 - ListGraph g;
1.42 - RevGraphWrapper<ListGraph> rgw(g);
1.43 - int result=algorithm(rgw);
1.44 - \endcode
1.45 - After running the algorithm, the original graph \c g
1.46 - is untouched.
1.47 - This techniques gives rise to an elegant code, and
1.48 - based on stable graph wrappers, complex algorithms can be
1.49 - implemented easily.
1.50 -
1.51 - In flow, circulation and bipartite matching problems, the residual
1.52 - graph is of particular importance. Combining a wrapper implementing
1.53 - this, shortest path algorithms and minimum mean cycle algorithms,
1.54 - a range of weighted and cardinality optimization algorithms can be
1.55 - obtained.
1.56 - For other examples,
1.57 - the interested user is referred to the detailed documentation of
1.58 - particular wrappers.
1.59 -
1.60 - The behavior of graph wrappers can be very different. Some of them keep
1.61 - capabilities of the original graph while in other cases this would be
1.62 - meaningless. This means that the concepts that they are models of depend
1.63 - on the graph wrapper, and the wrapped graph(s).
1.64 - If an edge of \c rgw is deleted, this is carried out by
1.65 - deleting the corresponding edge of \c g, thus the wrapper modifies the
1.66 - original graph.
1.67 - But for a residual
1.68 - graph, this operation has no sense.
1.69 - Let us stand one more example here to simplify your work.
1.70 - RevGraphWrapper has constructor
1.71 - \code
1.72 - RevGraphWrapper(Graph& _g);
1.73 - \endcode
1.74 - This means that in a situation,
1.75 - when a <tt> const ListGraph& </tt> reference to a graph is given,
1.76 - then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
1.77 - \code
1.78 - int algorithm1(const ListGraph& g) {
1.79 - RevGraphWrapper<const ListGraph> rgw(g);
1.80 - return algorithm2(rgw);
1.81 - }
1.82 - \endcode
1.83 -*/