marci@1172: /**
marci@1172:    @defgroup gwrappers Wrapper Classes for Graphs
marci@1172:    \brief This group contains several wrapper classes for graphs
marci@1172:    @ingroup graphs
marci@556:    
marci@1172:    The main parts of LEMON are the different graph structures, 
marci@1172:    generic graph algorithms, graph concepts which couple these, and 
marci@1172:    graph wrappers. While the previous ones are more or less clear, the 
marci@1172:    latter notion needs further explanation.
marci@1172:    Graph wrappers are graph classes which serve for considering graph 
marci@1172:    structures in different ways. A short example makes the notion much 
marci@1172:    clearer. 
marci@1172:    Suppose that we have an instance \c g of a directed graph
marci@1172:    type say \c ListGraph and an algorithm 
marci@1172:    \code template<typename Graph> int algorithm(const Graph&); \endcode 
marci@1172:    is needed to run on the reversely oriented graph. 
marci@1172:    It may be expensive (in time or in memory usage) to copy 
marci@1172:    \c g with the reverse orientation. 
marci@1172:    Thus, a wrapper class
marci@1172:    \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
marci@1172:    The code looks as follows
marci@1172:    \code
marci@1172:    ListGraph g;
marci@1172:    RevGraphWrapper<ListGraph> rgw(g);
marci@1172:    int result=algorithm(rgw);
marci@1172:    \endcode
marci@1172:    After running the algorithm, the original graph \c g 
marci@1172:    remains untouched. Thus the graph wrapper used above is to consider the 
marci@1172:    original graph with reverse orientation. 
marci@1172:    This techniques gives rise to an elegant code, and 
marci@1172:    based on stable graph wrappers, complex algorithms can be 
marci@1172:    implemented easily. 
marci@1172:    In flow, circulation and bipartite matching problems, the residual 
marci@1172:    graph is of particular importance. Combining a wrapper implementing 
marci@1172:    this, shortest path algorithms and minimum mean cycle algorithms, 
marci@1172:    a range of weighted and cardinality optimization algorithms can be 
marci@1172:    obtained. For lack of space, for other examples, 
marci@1172:    the interested user is referred to the detailed documentation of graph 
marci@1172:    wrappers. 
marci@1172:    The behavior of graph wrappers can be very different. Some of them keep 
marci@1172:    capabilities of the original graph while in other cases this would be 
marci@1172:    meaningless. This means that the concepts that they are a model of depend 
marci@1172:    on the graph wrapper, and the wrapped graph(s). 
marci@1172:    If an edge of \c rgw is deleted, this is carried out by 
marci@1172:    deleting the corresponding edge of \c g. But for a residual 
marci@1172:    graph, this operation has no sense. 
marci@1172:    Let we stand one more example here to simplify your work. 
marci@1172:    wrapper class
marci@1172:    \code template<typename Graph> class RevGraphWrapper; \endcode 
marci@1172:    has constructor 
marci@1172:    <tt> RevGraphWrapper(Graph& _g)</tt>. 
marci@1172:    This means that in a situation, 
marci@1172:    when a <tt> const ListGraph& </tt> reference to a graph is given, 
marci@1172:    then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
marci@1172:    \code
marci@1172:    int algorithm1(const ListGraph& g) {
marci@1172:    RevGraphWrapper<const ListGraph> rgw(g);
marci@1172:    return algorithm2(rgw);
marci@1172:    }
marci@1172:    \endcode
marci@1172: */