Next: Building Graphcode Up: omap Previous: omap Contents Index
It might seem obvious that omap could be made a templated type, with a single template parameter being the implementation of the omap. Unfortunately, omaps contain objects, which in turn have Ptrlists (the edge list), which used to maintain a reference to an omap. So objects and objrefs must be similarly parametrised by by the omap implementation type. However the omap implementation type will also need to reference the parametrised objrefs, leading to an implementation type parametrised by itself, an unparsable situation.
The way out of this dilemma is to make omap an abstract base class,
which can be made into a concrete implementation as part of the
definition of Graph. However, this introduces an extra level of
overhead in calling virtual functions when performing object
lookup, which is not insignificant. It also dramatically increases the complexity of coding
object::iterator, which also would need to be an abstract base
class.
In view of this, the macro based solution finally chosen, seemed the cleanest, and most efficient means of implementing different omap implementations.
Obviously, this reason is no longer relevant, however there doesn't seem to be any burning reason to change the macro parametrisation to a template argument.