Changeset 1172:37338ae42a2b in lemon-0.x for src

Timestamp:

02/23/05 23:00:05 (20 years ago)

Author:

marci

Branch:

default

Phase:

public

Convert:

svn:c9d7d8f5-90d6-0310-b91f-818b3a526b0e/lemon/trunk@1578

Message:

graphwrapper dox. everybody is asked to read doxygen.log

Location:

src/lemon

Files:

• graph_wrapper.h (modified) (1 diff)
• maps.h (modified) (1 diff)
• max_matching.h (modified) (1 diff)

src/lemon/graph_wrapper.h

@@ -35 +35 @@
   // Graph wrappers
 
-  /*! \addtogroup gwrappers
-    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
-
+  /*!
     \addtogroup gwrappers
     @{
-
+   */
+
+  /*! 
     Base type for the Graph Wrappers
 

src/lemon/maps.h

@@ -591 +591 @@
   ///
   ///For the sake of convenience it also works as a ususal map, i.e
-  ///<tt>operator[]</tt> and the \c Key and \c Valu typedefs also exist.
+  ///<tt>operator[]</tt> and the \c Key and \c Value typedefs also exist.
 
   template<class M> 

src/lemon/max_matching.h

@@ -162 +162 @@
     ///have the property that if \c g.oppositeNode(u,map[u])==v then
     ///\c \c g.oppositeNode(v,map[v])==u holds, and now some edge
-    ///joining \c u to \v will be an edge of the matching.
+    ///joining \c u to \c v will be an edge of the matching.
     template<typename NMapE>
     void readNMapEdge(NMapE& map) {