\( \newcommand{\E}{\mathrm{E}} \) \( \newcommand{\A}{\mathrm{A}} \) \( \newcommand{\R}{\mathrm{R}} \) \( \newcommand{\N}{\mathrm{N}} \) \( \newcommand{\Q}{\mathrm{Q}} \) \( \newcommand{\Z}{\mathrm{Z}} \) \( \def\ccSum #1#2#3{ \sum_{#1}^{#2}{#3} } \def\ccProd #1#2#3{ \sum_{#1}^{#2}{#3} }\)

CGAL 4.8 - Manual

All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Groups Pages
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Groups Pages
Polymorphic Return Types

Author
  Stefan Schirra (`stsch.nosp@m.irr@.nosp@m.mpi-s.nosp@m.b.mp.nosp@m.g.de`)

For some geometric operations, the type of the result of the operation is not fixed a priori, but depends on the input. Intersection computation is a prime example. The standard object-oriented approach to this is defining a common base class for all possible result types and returning a reference or a pointer to an object of the result type by a reference or pointer to the base class. Then all the virtual member functions in the interface of the base class can be applied to the result object and the implementation corresponding to the actual result type is called. It is hard to define appropriate base class interface functions (besides `draw()`).

CGAL has chosen a different approach, since CGAL wants to avoid large class hierarchies. With the CGAL class `Object`, you can fake a common base class, see Figure 0.1.

Figure 0.1 UML class diagram for faked object hierarchies (since 2.2-I-4).

Functions having a polymorphic return type create an object of the actual result type and wrap it into an object of type `Object`. Refer to the documentation of `CGAL::Object` class for more details.

An alternative is to use a class handling several output iterators at the same time such as the classes `CGAL::Dispatch_output_iterator`. and `CGAL::Dispatch_or_drop_output_iterator`.