CGAL 6.1.2 - Manual

Loading...
Searching...
No Matches
Namespaces

Author
  Stefan Schirra

Names, in particular (member) function names and class names should be descriptive and easily remembered. So it is not surprising that different libraries or packages choose the same name for corresponding or similar classes and functions. A common approach to avoid ambiguities is to add a prefix, for example, OpenGL adds `gl` and FLTK adds `fl`, but the better alternative is the usage of `namespace`.

# Namespace CGAL

All names introduced by CGAL should be in namespace `CGAL`, or in a subnamespace corresponding to a package, e.g.:

#include <something>
namespace CGAL {
class Foo {};
namespace Polygon_mesh_processing {
void
bar( foo & f);
} // namespace Polygon_mesh_processing
} // namespace CGAL
CGAL

Make sure not to have include statements inside the `namespace CGAL`. Otherwise, all names defined in the file included will be added to the namespace.

# Namespace internal

All names introduced by CGAL which are not documented to the user should be under an `internal` subnamespace of `CGAL`, e.g.:

namespace CGAL {
namespace Polygon_mesh_processing {
namespace internal {
class Baz_used_by_foo {};
} // namespace internal
} // namespace Polygon_mesh_processing
} // namespace CGAL

# Note on global template functions

According to the resolutions of the following issues in the forthcoming C++-standard ( 225, 226 and 229 ):

> Unless otherwise specified, no global or non-member function in the standard library shall use a function from another namespace which is found through argument-dependent name lookup

the namespace `CGAL::NTS` does not need to be used anymore (currently `CGAL_NTS` macro boils down to `CGAL::`).

# Requirements and recommendations

Requirements:

- all names defined by CGAL are in namespace `CGAL` (including namespaces nested in namespace `CGAL`).
- explicitly prefix calls to template functions of CGAL (such as `square`, `sign`, `abs`, \( \dots\) ) by `CGAL::` to ensure the functions used are the one from CGAL and not one from another library. If you want to allow an optimized function from another library to be used, then you should not qualify the call and document it explicitly (if appropriate).