Index: doc/Makefile.am
===================================================================
 doc/Makefile.am (revision 1400)
+++ doc/Makefile.am (revision 1401)
@@ 9,5 +9,5 @@
demoprograms.dox graphs.dox undir_graphs.dox namedparam.dox \
maps.dox coding_style.dox groups.dox namespaces.dox license.dox \
 developers_interface.dox graph_io.dox dirs.dox gwrappers.dox
+ developers_interface.dox graph_io.dox dirs.dox graphadaptors.dox
Index: doc/graphadaptors.dox
===================================================================
 doc/graphadaptors.dox (revision 1401)
+++ doc/graphadaptors.dox (revision 1401)
@@ 0,0 +1,80 @@
+/**
+ @defgroup graph_adaptors Adaptor Classes for Graphs
+ \brief This group contains several adaptor classes for graphs
+ @ingroup graphs
+
+ The main parts of LEMON are the different graph structures,
+ generic graph algorithms, graph concepts which couple these, and
+ graph adaptors. While the previous notions are more or less clear, the
+ latter one needs further explanation.
+ Graph adaptors are graph classes which serve for considering graph
+ structures in different ways.
+
+ A short example makes this much
+ clearer.
+ Suppose that we have an instance \c g of a directed graph
+ type say ListGraph and an algorithm
+ \code template int algorithm(const Graph&); \endcode
+ is needed to run on the reversed oriented graph.
+ It may be expensive (in time or in memory usage) to copy
+ \c g with the reversed orientation.
+ In this case, an adaptor class is used, which
+ (according to LEMON graph concepts) works as a graph.
+ The adaptor uses
+ the original graph structure and graph operations when methods of the
+ reversed oriented graph are called.
+ This means that the adaptor have minor memory usage,
+ and do not perform sophisticated algorithmic actions.
+ The purpose of it is to give a tool for the cases when
+ a graph have to be used in a specific alteration.
+ If this alteration is obtained by a usual construction
+ like filtering the edgeset or considering a new orientation, then
+ an adaptor is worthwhile to use.
+ To come back to the reversed oriented graph, in this situation
+ \code template class RevGraphAdaptor; \endcode
+ template class can be used.
+ The code looks as follows
+ \code
+ ListGraph g;
+ RevGraphAdaptor rgw(g);
+ int result=algorithm(rgw);
+ \endcode
+ After running the algorithm, the original graph \c g
+ is untouched.
+ This techniques gives rise to an elegant code, and
+ based on stable graph adaptors, complex algorithms can be
+ implemented easily.
+
+ In flow, circulation and bipartite matching problems, the residual
+ graph is of particular importance. Combining an adaptor implementing
+ this, shortest path algorithms and minimum mean cycle algorithms,
+ a range of weighted and cardinality optimization algorithms can be
+ obtained.
+ For other examples,
+ the interested user is referred to the detailed documentation of
+ particular adaptors.
+
+ The behavior of graph adaptors can be very different. Some of them keep
+ capabilities of the original graph while in other cases this would be
+ meaningless. This means that the concepts that they are models of depend
+ on the graph adaptor, and the wrapped graph(s).
+ If an edge of \c rgw is deleted, this is carried out by
+ deleting the corresponding edge of \c g, thus the adaptor modifies the
+ original graph.
+ But for a residual
+ graph, this operation has no sense.
+ Let us stand one more example here to simplify your work.
+ RevGraphAdaptor has constructor
+ \code
+ RevGraphAdaptor(Graph& _g);
+ \endcode
+ This means that in a situation,
+ when a const ListGraph& reference to a graph is given,
+ then it have to be instantiated with Graph=const ListGraph.
+ \code
+ int algorithm1(const ListGraph& g) {
+ RevGraphAdaptor rgw(g);
+ return algorithm2(rgw);
+ }
+ \endcode
+*/
Index: doc/groups.dox
===================================================================
 doc/groups.dox (revision 1329)
+++ doc/groups.dox (revision 1401)
@@ 32,5 +32,5 @@
is to be shrunk for an other algorithm.
LEMON also provides a variety of graphs for these requirements called
\ref gwrappers "graph wrappers". Wrappers cannot be used alone but only
+\ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only
in conjunction with other graph representation.
Index: doc/gwrappers.dox
===================================================================
 doc/gwrappers.dox (revision 1252)
+++ (revision )
@@ 1,80 +1,0 @@
/**
 @defgroup gwrappers Wrapper Classes for Graphs
 \brief This group contains several wrapper classes for graphs
 @ingroup graphs

 The main parts of LEMON are the different graph structures,
 generic graph algorithms, graph concepts which couple these, and
 graph wrappers. While the previous notions are more or less clear, the
 latter one needs further explanation.
 Graph wrappers are graph classes which serve for considering graph
 structures in different ways.

 A short example makes this much
 clearer.
 Suppose that we have an instance \c g of a directed graph
 type say ListGraph and an algorithm
 \code template int algorithm(const Graph&); \endcode
 is needed to run on the reversed oriented graph.
 It may be expensive (in time or in memory usage) to copy
 \c g with the reversed orientation.
 In this case, a wrapper class is used, which
 (according to LEMON graph concepts) works as a graph.
 The wrapper uses
 the original graph structure and graph operations when methods of the
 reversed oriented graph are called.
 This means that the wrapper have minor memory usage,
 and do not perform sophisticated algorithmic actions.
 The purpose of it is to give a tool for the cases when
 a graph have to be used in a specific alteration.
 If this alteration is obtained by a usual construction
 like filtering the edgeset or considering a new orientation, then
 a wrapper is worthwhile to use.
 To come back to the reversed oriented graph, in this situation
 \code template class RevGraphWrapper; \endcode
 template class can be used.
 The code looks as follows
 \code
 ListGraph g;
 RevGraphWrapper rgw(g);
 int result=algorithm(rgw);
 \endcode
 After running the algorithm, the original graph \c g
 is untouched.
 This techniques gives rise to an elegant code, and
 based on stable graph wrappers, complex algorithms can be
 implemented easily.

 In flow, circulation and bipartite matching problems, the residual
 graph is of particular importance. Combining a wrapper implementing
 this, shortest path algorithms and minimum mean cycle algorithms,
 a range of weighted and cardinality optimization algorithms can be
 obtained.
 For other examples,
 the interested user is referred to the detailed documentation of
 particular wrappers.

 The behavior of graph wrappers can be very different. Some of them keep
 capabilities of the original graph while in other cases this would be
 meaningless. This means that the concepts that they are models of depend
 on the graph wrapper, and the wrapped graph(s).
 If an edge of \c rgw is deleted, this is carried out by
 deleting the corresponding edge of \c g, thus the wrapper modifies the
 original graph.
 But for a residual
 graph, this operation has no sense.
 Let us stand one more example here to simplify your work.
 RevGraphWrapper has constructor
 \code
 RevGraphWrapper(Graph& _g);
 \endcode
 This means that in a situation,
 when a const ListGraph& reference to a graph is given,
 then it have to be instantiated with Graph=const ListGraph.
 \code
 int algorithm1(const ListGraph& g) {
 RevGraphWrapper rgw(g);
 return algorithm2(rgw);
 }
 \endcode
*/