\( \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 5.0.4 - Manual
General Information

The chapter explains some basic features of CGAL such as thread safety, code deprecation, checking of pre- and postconditions and altering the failure behavior, and how to control inlining.

These concepts are further developed in the Developer Manual.

Namespace CGAL

All names introduced by CGAL, especially those documented in these manuals, are in a namespace called CGAL, which is in global scope. A user can either qualify names from CGAL by adding CGAL::, e.g., CGAL::Point_2< CGAL::Exact_predicates_inexact_constructions_kernel >, make a single name from CGAL visible in a scope via a using statement, e.g., using CGAL::Point_2;, and then use this name unqualified in this scope, or even make all names from namespace CGAL visible in a scope with using namespace CGAL;. The latter, however, is likely to give raise to name conflicts and is therefore not recommended.

Thread Safety

CGAL is progressively being made thread-safe. The guidelines which are followed are:

  • it should be possible to use different objects in different threads at the same time (of the same type or not),
  • it is not safe to access the same object from different threads at the same time, unless otherwise specified in the class documentation.

If the macro CGAL_HAS_THREADS is not defined, then CGAL assumes it can use any thread-unsafe code (such as static variables). By default, this macro is not defined, unless BOOST_HAS_THREADS or _OPENMP is defined. It is possible to force its definition on the command line, and it is possible to prevent its default definition by setting CGAL_HAS_NO_THREADS from the command line.

C++14 Support

After being based on the C++ standard released in 1998 (and later refined in 2003) for a long time, CGAL is now based on a newer major version of the standard, C++14.

Functor Return Types

CGAL functors support the result_of protocol. If a functor F has the same return type across all overloads of operator(), the nested type F::result_type is defined to be that type. Otherwise the return type of calling the functor with an argument of type Arg can be accessed through CGAL::cpp11::result_of<F(Arg)>::type .

Checks

Much of the CGAL code contains assert statements for preconditions, and postconditions of functions as well as in the code. These assertions can be switched on and off per package and the user can change the error behaviour. For details see Section Checks of Chapter Chapter_STL_Extensions_for_CGAL.

Compile-time Flags to Control Inlining

Making functions inlined can, at times, improve the efficiency of your code. However this is not always the case and it can differ for a single function depending on the application in which it is used. Thus CGAL defines a set of compile-time macros that can be used to control whether certain functions are designated as inlined functions or not. The following table lists the macros and their default values, which are set in one of the CGAL include files.

Macro Name Default
CGAL_KERNEL_INLINE inline
CGAL_KERNEL_MEDIUM_INLINE
CGAL_KERNEL_LARGE_INLINE
CGAL_MEDIUM_INLINE inline
CGAL_LARGE_INLINE
CGAL_HUGE_INLINE

If you wish to change the value of one or more of these macros, you can simply give it a new value when compiling. For example, to make functions that use the macro CGAL_KERNEL_MEDIUM_INLINE inline functions, you should set the value of this macro to inline instead of the default blank.

Note that setting inline manually is very fragile, especially in a template context. It is usually better to let the compiler select by himself which functions should be inlined or not.