... |
... |
@@ -37,8 +37,8 @@
|
37 |
37 |
//
|
38 |
|
// The simple graph's can be refered as two containers, one node container
|
39 |
|
// and one edge container. But they are not standard containers they
|
40 |
|
// does not store values directly they are just key continars for more
|
41 |
|
// value containers which are the node and edge maps.
|
|
38 |
// The simple graphs can be refered as two containers: a node container
|
|
39 |
// and an edge container. But they do not store values directly, they
|
|
40 |
// are just key continars for more value containers, which are the
|
|
41 |
// node and edge maps.
|
42 |
42 |
//
|
43 |
|
// The graph's node and edge sets can be changed as we add or erase
|
|
43 |
// The node and edge sets of the graphs can be changed as we add or erase
|
44 |
44 |
// nodes and edges in the graph. LEMON would like to handle easily
|
... |
... |
@@ -47,3 +47,3 @@
|
47 |
47 |
// the current indicing key that cause a drawback in the performance
|
48 |
|
// in the library. We use another solution we notify all maps about
|
|
48 |
// in the library. We use another solution: we notify all maps about
|
49 |
49 |
// an alteration in the graph, which cause only drawback on the
|
... |
... |
@@ -51,15 +51,16 @@
|
51 |
51 |
//
|
52 |
|
// This class provides an interface to the container. The \e first() and \e
|
53 |
|
// next() member functions make possible to iterate on the keys of the
|
54 |
|
// container. The \e id() function returns an integer id for each key.
|
55 |
|
// The \e maxId() function gives back an upper bound of the ids.
|
|
52 |
// This class provides an interface to a node or edge container.
|
|
53 |
// The first() and next() member functions make possible
|
|
54 |
// to iterate on the keys of the container.
|
|
55 |
// The id() function returns an integer id for each key.
|
|
56 |
// The maxId() function gives back an upper bound of the ids.
|
56 |
57 |
//
|
57 |
58 |
// For the proper functonality of this class, we should notify it
|
58 |
|
// about each alteration in the container. The alterations have four type
|
59 |
|
// as \e add(), \e erase(), \e build() and \e clear(). The \e add() and
|
60 |
|
// \e erase() signals that only one or few items added or erased to or
|
61 |
|
// from the graph. If all items are erased from the graph or from an empty
|
62 |
|
// graph a new graph is builded then it can be signaled with the
|
|
59 |
// about each alteration in the container. The alterations have four type:
|
|
60 |
// add(), erase(), build() and clear(). The add() and
|
|
61 |
// erase() signal that only one or few items added or erased to or
|
|
62 |
// from the graph. If all items are erased from the graph or if a new graph
|
|
63 |
// is built from an empty graph, then it can be signaled with the
|
63 |
64 |
// clear() and build() members. Important rule that if we erase items
|
64 |
|
// from graph we should first signal the alteration and after that erase
|
|
65 |
// from graphs we should first signal the alteration and after that erase
|
65 |
66 |
// them from the container, on the other way on item addition we should
|
... |
... |
@@ -68,6 +69,6 @@
|
68 |
69 |
// The alteration can be observed with a class inherited from the
|
69 |
|
// \e ObserverBase nested class. The signals can be handled with
|
|
70 |
// ObserverBase nested class. The signals can be handled with
|
70 |
71 |
// overriding the virtual functions defined in the base class. The
|
71 |
72 |
// observer base can be attached to the notifier with the
|
72 |
|
// \e attach() member and can be detached with detach() function. The
|
|
73 |
// attach() member and can be detached with detach() function. The
|
73 |
74 |
// alteration handlers should not call any function which signals
|
... |
... |
@@ -76,18 +77,18 @@
|
76 |
77 |
//
|
77 |
|
// Alteration observers try to be exception safe. If an \e add() or
|
78 |
|
// a \e clear() function throws an exception then the remaining
|
|
78 |
// Alteration observers try to be exception safe. If an add() or
|
|
79 |
// a clear() function throws an exception then the remaining
|
79 |
80 |
// observeres will not be notified and the fulfilled additions will
|
80 |
|
// be rolled back by calling the \e erase() or \e clear()
|
81 |
|
// functions. Thence the \e erase() and \e clear() should not throw
|
82 |
|
// exception. Actullay, it can be throw only \ref ImmediateDetach
|
83 |
|
// exception which detach the observer from the notifier.
|
|
81 |
// be rolled back by calling the erase() or clear() functions.
|
|
82 |
// Hence erase() and clear() should not throw exception.
|
|
83 |
// Actullay, they can throw only \ref ImmediateDetach exception,
|
|
84 |
// which detach the observer from the notifier.
|
84 |
85 |
//
|
85 |
|
// There are some place when the alteration observing is not completly
|
|
86 |
// There are some cases, when the alteration observing is not completly
|
86 |
87 |
// reliable. If we want to carry out the node degree in the graph
|
87 |
|
// as in the \ref InDegMap and we use the reverseEdge that cause
|
|
88 |
// as in the \ref InDegMap and we use the reverseArc(), then it cause
|
88 |
89 |
// unreliable functionality. Because the alteration observing signals
|
89 |
|
// only erasing and adding but not the reversing it will stores bad
|
90 |
|
// degrees. The sub graph adaptors cannot signal the alterations because
|
91 |
|
// just a setting in the filter map can modify the graph and this cannot
|
92 |
|
// be watched in any way.
|
|
90 |
// only erasing and adding but not the reversing, it will stores bad
|
|
91 |
// degrees. Apart form that the subgraph adaptors cannot even signal
|
|
92 |
// the alterations because just a setting in the filter map can modify
|
|
93 |
// the graph and this cannot be watched in any way.
|
93 |
94 |
//
|
... |
... |
@@ -105,9 +106,9 @@
|
105 |
106 |
|
106 |
|
// \brief Exception which can be called from \e clear() and
|
107 |
|
// \e erase().
|
|
107 |
// \brief Exception which can be called from clear() and
|
|
108 |
// erase().
|
108 |
109 |
//
|
109 |
|
// From the \e clear() and \e erase() function only this
|
|
110 |
// From the clear() and erase() function only this
|
110 |
111 |
// exception is allowed to throw. The exception immediatly
|
111 |
112 |
// detaches the current observer from the notifier. Because the
|
112 |
|
// \e clear() and \e erase() should not throw other exceptions
|
|
113 |
// clear() and erase() should not throw other exceptions
|
113 |
114 |
// it can be used to invalidate the observer.
|
... |
... |
@@ -123,4 +124,3 @@
|
123 |
124 |
// to override. The add() and erase() functions are
|
124 |
|
// to notify the oberver when one item is added or
|
125 |
|
// erased.
|
|
125 |
// to notify the oberver when one item is added or erased.
|
126 |
126 |
//
|