- Update methods are generally closed with respect to the class they belong to. This means, for example, that the new_edge method of our plan_undi_graph class is expressed in a way that is implicitly safe with respect to the class planarity predicate: in order to create a new edge the programmer has to specify a face to be split and two nodes on the face border. This policy allows to detect illegal operations on graphs at compile time, provided that each class hides the inherited methods which are not legal anymore. When it is not possible (or convenient) to define an update method in an implicitly safe way, a pre-condition check is performed.
- Given a parent class A and a derived class B, operators are always provided to execute a=b and b=a, where a and b respectively are objects (instances) of the A and B classes.
- The root undi_graph class does not derive from the LEDA graph class, it just contains a pointer to a graph instance. The reason why we decided not to derive from graph is that we wanted our classes to actually contain only pointers: this a very important issue for efficiency, when handling large graphs. The following two sub-sections explain why.
- Suppose you have a parent class A, and a class B derived from A and containing some additional attributes and methods, say A holds nodes and edges, and A holds and additional list of faces and some face-management methods. When you have an object a of class A, containing a large graph, and you want to promote it to class B, it could be very expensive to use B::operator=(A): such an operator, in fact, would copy a into the A-part of b, and then would build the face list into b.
- Our approach, beside providing such an assigment operator, is to also provide a special constructor B::B(A& a) taking advantage of our dynamic implementation, and actually copying just the pointers from a to b, making a pointing to a new empty graph (in order to avoid side effects) and then only building the face list into b . We shortly describe this by saying that B b(a)creates a new object b by stealing the contents of a.
- Stealing constructors are provided in order efficiently initialize an instance of any class (within our hierarchy) by stealing the contents (i.e. mirroring the pointers) of an instance of any ancestor class, and by accordingly building the remaining parts.
Last update: July 31, 2002
Website design by INTEGRA Sistemi, www.IntegraSistemi.it