doc/named-param.dox
author deba
Wed, 01 Mar 2006 10:25:30 +0000
changeset 1991 d7442141d9ef
parent 1713 49d22d34d95f
child 2391 14a343be7a5a
permissions -rw-r--r--
The graph adadptors can be alteration observed.
In most cases it uses the adapted graph alteration notifiers.
Only special case is now the UndirGraphAdaptor, where
we have to proxy the signals from the graph.

The SubBidirGraphAdaptor is removed, because it doest not
gives more feature than the EdgeSubGraphAdaptor<UndirGraphAdaptor<Graph>>.

The ResGraphAdaptor is based on this composition.
alpar@1624
     1
/*!
alpar@954
     2
alpar@953
     3
\page named-param Named Parameters
alpar@953
     4
alpar@1624
     5
\section named-func-param Named Function Parameters
alpar@955
     6
alpar@1536
     7
C++ makes it possible to use default parameter values when calling a
alpar@1536
     8
function. In such a case we do not have to give value for parameters,
alpar@1536
     9
the program will use the default ones.  Unfortunately sometimes this
alpar@1536
    10
is not enough. If we do not want to give values for all the
alpar@1536
    11
parameters, only for some of them we come across problems, because an
alpar@1536
    12
arbitrary set of parameters cannot be omitted. On the other hand
alpar@1536
    13
parameters have a fixed order in the head of the function.  C++ can
alpar@1536
    14
apply the default values only in the back of the order, if we do not
alpar@1536
    15
give other value for them.  So we can not give the function for
alpar@1536
    16
example the value of the first, and the third parameter, expecting
alpar@1536
    17
that the program will aplly the default value for the second
alpar@1536
    18
parameter.  However sometimes we would like to use some functinos
alpar@1536
    19
exactly in this way. With a crafty trick and with some little
alpar@1536
    20
inconvenience this is possible. We have implemented this little trick
alpar@1536
    21
as an example below.
hegyi@1141
    22
hegyi@1141
    23
\code
alpar@1713
    24
class namedFn 
hegyi@1141
    25
{
hegyi@1141
    26
  int _id;
hegyi@1141
    27
  double _val;
hegyi@1141
    28
  int _dim;
hegyi@1141
    29
  
hegyi@1141
    30
  public:
alpar@1713
    31
  namedFn() : _id(0), _val(1), _dim(2) {}
alpar@1713
    32
  namedFn& id(int p)     { _id  = p ; return *this; }
alpar@1713
    33
  namedFn& val(double p) { _val = p ; return *this; }
alpar@1713
    34
  namedFn& dim(int p)    { _dim = p ; return *this; }
hegyi@1141
    35
hegyi@1141
    36
  run() {
hegyi@1141
    37
    printf("Here is the function itself.");
hegyi@1141
    38
  }
hegyi@1141
    39
};
hegyi@1141
    40
\endcode
hegyi@1141
    41
hegyi@1141
    42
hegyi@1141
    43
The usage is the following.
hegyi@1141
    44
alpar@1713
    45
We have to define a class, let's call it \c namedFn.  Let us assume that
alpar@1713
    46
we would like to use a parameter, called \c X. In the \c namedFn class we
alpar@1624
    47
have to define an \c _X attribute, and a function \c X. The function
alpar@1624
    48
expects a parameter with the type of \c _X, and sets the value of
alpar@1624
    49
\c _X. After setting the value the function returns the class itself. The
alpar@1624
    50
class also have to have a function, called for example <tt>run()</tt>, we have
alpar@1536
    51
to implement here the original function itself. The constructor of the
alpar@1624
    52
class have to give all the attributes like \c _X the default values of
alpar@1536
    53
them.
hegyi@1141
    54
alpar@1536
    55
If we instantiate this class, the default values will be set for the
hegyi@1619
    56
attributes (originally the parameters), initially. If we call function
alpar@1624
    57
\c X, we get a class with the modified parameter value of
alpar@1713
    58
\c X. Therefore we can modify any parameter-value, independently from the
alpar@1624
    59
order. To run the algorithm we have to call the <tt>run()</tt> function at the
alpar@1536
    60
end of the row.
hegyi@1141
    61
alpar@1624
    62
Example:
alpar@1624
    63
\code
alpar@1713
    64
namedFn().id(3).val(2).run();
alpar@1624
    65
\endcode
alpar@955
    66
alpar@1713
    67
\note Although it is a class, namedFn is used pretty much like as it were
alpar@1713
    68
a function. That it why it is called namedFn and not \c NamedFn.
alpar@1713
    69
alpar@1713
    70
\note In fact, the final <tt>.run()</tt> could be made unnecessary if the
alpar@1713
    71
actual function code were put in the destructor instead. This however would make
alpar@1713
    72
hard to implement functions with return values, and would also make the
alpar@1713
    73
implementation of \ref named-templ-func-param "named template parameters"
alpar@1929
    74
very problematic. <b>Therefore, by convention, <tt>.run()</tt> must be used
alpar@1929
    75
to explicitly execute function having named parameters in Lemon.</b>
alpar@1713
    76
alpar@1713
    77
alpar@955
    78
\section traits-classes Traits Classes
alpar@955
    79
alpar@1536
    80
The procedure above can also be applied when defining classes. In this
alpar@1536
    81
case the type of the attributes can be changed.  Initially we have to
alpar@1536
    82
define a class with the default attribute types. This is the so called
alpar@1536
    83
Traits Class. Later on the types of these attributes can be changed,
alpar@1536
    84
as described below. In our software \ref lemon::DijkstraDefaultTraits is an
alpar@1536
    85
example of how a traits class looks like.
hegyi@1141
    86
alpar@955
    87
\section named-templ-param Named Class Template Parameters
alpar@954
    88
alpar@1536
    89
If we would like to change the type of an attribute in a class that
alpar@1536
    90
was instantiated by using a traits class as a template parameter, and
alpar@1536
    91
the class contains named parameters, we do not have to reinstantiate
alpar@1536
    92
the class with new traits class. Instead of that, adaptor classes can
alpar@1536
    93
be used like in the following cases.
hegyi@1141
    94
alpar@954
    95
\code
deba@1709
    96
Dijkstra<>::SetPredNodeMap<NullMap<Node,Node> >::Create
alpar@954
    97
\endcode
hegyi@1141
    98
alpar@954
    99
It can also be used in conjunction with other named template
alpar@954
   100
parameters in arbitrary order.
hegyi@1141
   101
alpar@954
   102
\code
deba@1709
   103
Dijkstra<>::SetDistMap<MyMap>::SetPredMap<NullMap<Node,Edge> >::Create
alpar@954
   104
\endcode
alpar@954
   105
alpar@1536
   106
The result will be an instantiated Dijkstra class, in which the
alpar@1536
   107
DistMap and the PredMap is modified.
hegyi@1141
   108
alpar@1624
   109
\section named-templ-func-param Named Function Template Parameters
alpar@955
   110
alpar@1536
   111
If the class has so called wizard functions, the new class with the
alpar@1536
   112
modified tpye of attributes can be returned by the appropriate wizard
alpar@1536
   113
function. The usage of these wizard functions is the following:
alpar@953
   114
alpar@953
   115
*/