diff -r f426c84a4e00 -r 37338ae42a2b doc/gwrappers.dox
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/gwrappers.dox	Wed Feb 23 22:00:05 2005 +0000
@@ -0,0 +1,61 @@
+/**
+   @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 ones are more or less clear, the 
+   latter notion needs further explanation.
+   Graph wrappers are graph classes which serve for considering graph 
+   structures in different ways. A short example makes the notion much 
+   clearer. 
+   Suppose that we have an instance \c g of a directed graph
+   type say \c ListGraph and an algorithm 
+   \code template<typename Graph> int algorithm(const Graph&); \endcode 
+   is needed to run on the reversely oriented graph. 
+   It may be expensive (in time or in memory usage) to copy 
+   \c g with the reverse orientation. 
+   Thus, a wrapper class
+   \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
+   The code looks as follows
+   \code
+   ListGraph g;
+   RevGraphWrapper<ListGraph> rgw(g);
+   int result=algorithm(rgw);
+   \endcode
+   After running the algorithm, the original graph \c g 
+   remains untouched. Thus the graph wrapper used above is to consider the 
+   original graph with reverse orientation. 
+   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 lack of space, for other examples, 
+   the interested user is referred to the detailed documentation of graph 
+   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 a model 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. But for a residual 
+   graph, this operation has no sense. 
+   Let we stand one more example here to simplify your work. 
+   wrapper class
+   \code template<typename Graph> class RevGraphWrapper; \endcode 
+   has constructor 
+   <tt> RevGraphWrapper(Graph& _g)</tt>. 
+   This means that in a situation, 
+   when a <tt> const ListGraph& </tt> reference to a graph is given, 
+   then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
+   \code
+   int algorithm1(const ListGraph& g) {
+   RevGraphWrapper<const ListGraph> rgw(g);
+   return algorithm2(rgw);
+   }
+   \endcode
+*/