STL Extensions for CGAL

*Michael Hoffmann, Lutz Kettner, Sylvain Pion, and Ron Wein*

55.1 | Doubly-Connected List Managing Items in Place | ||||

55.2 | Compact Container | ||||

55.3 | Multiset with Extended Functionality | ||||

55.4 | Functor Adaptors |

CGAL is designed in the spirit of the generic programming paradigm
to work together with the Standard Template Library (STL)
[C`++`98, Aus98]. This chapter documents non-geometric
STL-like components that are not provided in the STL standard but
in CGAL: a doubly-connected list managing items in place (where
inserted items are not copied), a compact container, a multi-set class that
uses three-valued comparisons and offers additional functionality,
generic algorithms, iterators, functor adaptors for binding and swapping
arguments and for composition, functors for projection and creation and
adaptor classes around iterators and circulators. See also circulators in
Chapter 57.

The class *In_place_list<T,bool>* manages a
sequence of items in place in a doubly-connected list. Its goals are
the flexible handling of memory management and performance
optimization. The item type has to provide the two necessary
pointers *&T::next_link* and *&T::prev_link*. One possibility
to obtain these pointers is to inherit them from the base class
*In_place_list_base<T>*.

The class *In_place_list<T,bool>* is a container quite similar
to STL containers, with the advantage that it is able to handle the
stored elements by reference instead of copying them. It is possible
to delete an element only knowing its address and no iterator to it.
This used to simplify mutually pointed data structures like a halfedge
data structure for planar maps or polyhedral surfaces (the current design
does not need this anymore). The usual iterators are also available.

The main deviation from the STL container concept is that the *++* and
*--* operators of the iterator do not have a constant time complexity in
all cases. The actual complexity is related to the maximum size that the
container has had during its life time compared to its current size, because
the iterator has to go over the "erased" elements as well, so the bad case is
when the container used to contain lots of elements, but now has far less. In
this case, we suggest to do a copy of the container in order to "defragment"
the internal representation.

This container has been developed in order to efficiently handle large data structures like the triangulation and halfedge data structures. It can probably be useful for other kinds of graphs as well.

The class *Multiset<Type,Compare,Allocator>* represents a
multi-set of elements of type *Type*, represented as a red-black tree
(see [CLRS01, Chapter 13] for an excellent introduction to red-black
trees). It differs from the STL's *multiset* class-template mainly due
to the fact that it is parameterized by a comparison functor *Compare*
that returns the three-valued *Comparison_result* (namely it returns
either *SMALLER*, *EQUAL*, or *LARGER*), rather than a *less*
functor returning *bool*. Thus, it is possible to maintain
the underlying red-black tree with less invocations of the comparison functor,
which can considerably decrease running times, especially when comparing
elements of type *Type* is an expensive operation.

*Multiset<Type,Compare,Allocator>* also guarantees that the order of
elements sent to the comparison functor is fixed. For example, if we insert
a new element *x* into the set (or erase an element from the set), then
we always invoke *Compare() (x, y)* (and never *Compare() (y, x)*),
where *y* is an element already stored in the set. This behavior, not
supported by *std::multiset*, is sometimes crucial for designing more
efficient comparison predicates.

The interface of *Multiset<Type,Compare,Allocator>* is in general
derived from *std::multiset*. However, it extends the interface by
offering some additional operations, such as: inserting of an element into
the set given its *exact* position (and not just using an insertion hint);
looking up keys whose type may differ from *Type*, as long as users supply
a comparison functor *CompareKey*, between the keys and set elements;
and catenating and splitting sets.

The standard library contains some adaptors for binding functors, that is fixing one argument of a functor to a specific value thereby creating a new functor that takes one argument less than the original functor. Also, though non-standard, some STL implementations (such as SGI) provide adaptors to compose function objects. Unfortunately, these bind and compose adaptors are limited to unary and binary functors only, and these functors must not be overloaded.

Since there are a number of functors in CGAL that take more than two arguments, and since functors may also be overloaded, i.e., accept several different sets of arguments, we have to define our own adaptors to be used with CGAL functors.